Cutting 1.0

1

As far as I’m concerned, the current code can be brought out under a stable version. The idea is to stay on 1.x for a long time, at least for the core packages, to avoid the awkwardness of various modules depending on incompatible versions of the core packages. So we’re going to be prioritizing backwards compatibility over elegance when making changes.

Is there anything anyone feels should be addressed before releasing 1.0.0?

Any comments regarding the release process? (I’ve considered doing unstable channels, but I feel at the current community size the mental and release-engineering overhead is more than the gain, so we’re going to continue with a model where we just release a version for real, and follow up with patch releases if issues are found.)

Anything else?

2 Likes
2

Not sure if this is a big thing, but I noticed that if user places a table or a block-level leaf node at the end of a text container, they have issues moving the cursor below it. I have solved it by defining the content as having to contain one last element that is heading, paragraph, heading or code block, but I’m not sure if that’s the best way to do it. Other than that, everything is really good as it is. Good idea to stabilize things!

3

Have you tried enabling the gap cursor plugin?

4

Yes, I am using the gap cursor plugin, but I am not sure where that gap cursor would show. It doesn’t seem to show in the situation mentioned above for me. But maybe I need to include some extra CSS or so?

5

Yes, style/gapcursor.css from the gapcursor package. I’ve added some docs to make this harder to miss.

6

Thanks! I see, I guess I just assumed it would work the same as dropcursor, as that one didn’t require any extra CSS.

7

Is there a recommended way of controlling where the gapcursor goes? I have a set document structure like this:

doc(article(title(...),...,body(...)))

If there is only a table in the body and I move the cursor with the arrow keys to the right from the last table cell, the gap caret blinks horizontally and is being put after the article node:

doc(article(title(...),...,body(table(...)))|)

Rather than, as I would expect, after the table:

doc(article(title(...),...,body(table(...)|)))

If the user inputs any keys with the gap cursor there, the input goes into the last table cell rather than starting a new paragraph after the table. If I hit “Enter”, I would expect for a new, empty paragraph to be formed after the table, but nothing happens.

8

Could you open a separate thread about this? It’s helpful if threads stay somewhat on topic.

1 Like
9

I’m currently working 99% of my time on finishing a CMS using prosemirror (i’ll give links and free accounts when it’s ready). As you noticed i come back often here to reflect problems i can find (that are sometimes not on my side).

I’m not asking you wait for me to finish, but i have the feeling i could report more small problems in the next few days (about one week or so). For example the first time i tried gapcursor it was throwing errors at me so i stopped, but i am willing to try harder later this week.

So maybe today you set a deadline like xxth october final release ? To give us the few days to report back final issues ?

10

Does this mean that things like Mark location and behavior have fully stabilized and will hold steady through the 1.x series? Sorry if this is addressed and I missed it.

My team is very excited about the work we’re doing around Prosemirror and can’t wait to see what grows up around it now that it’s reaching a stable release.

11

Yes, in that any further changes will be backwards-compatible.

1 Like
12

The thing is that there’s always something going on, and if you keep pushing the release date back for each new thing that goes on, you never actually get to the point where you release. I’m letting this thread sit for a few more days to give people a chance to respond, but no more.

No big conceptual changes are going to be made anymore anyway, and bug fixes can also be made after the 1.0 release.

13

1.0 means stability. I’m definitely in favor of that.

14

With a 1.0 announcement will you be listing projects that use ProseMirror? Although mines not 100% where I want it yet, I’d definitely love for my project to be in any list! If so, maybe start another thread to gather projects that want to be listed?

Much love and very excited about 1.0!

15

I’ve been keeping such a list for CodeMirror, and I’ve found it gets kind of tedious to maintain (and I’m planning to get rid of it there). So probably not. I’ll gladly tweet or retweet projects from the twitter account though.

16

I noticed that the prosemirror-tables module still depends on 0.23.0. Is there any non-trivial change blocking it from being updated to the 0.24.0 version? I guess this would be the only thing blocking a 1.0.0 release from my perspective.

Apart from that, releasing 1.0.0 sounds good! Congrats on the overall stability ProseMirror has attained by now :slight_smile: I’m looking forward to the release!

17

No—it’ll catch up at some point. Note that I’m not directly maintaining this module, so it’s not part of my workflow. (Which, after 1.0, will be less jarring because versions won’t have to be kept in lockstep anymore.)

1 Like
18

That sounds great. I haven’t had too much trouble in upgrading between the 0.x versions, but it’d be nice to track a stable release for a while.

19

Sounds good to me.

20

Would it be possible to include type definitions in the release and maintain them there instead of in the DefinitelyTyped repository.