Consider identifying unstable releases (mark as alpha?)

Do you want to request a feature or report a bug?

Discussion

What’s the current behavior?

Currently, when we publish a version of Slate, the version doesn’t indicate a potentially unstable version.

Slate is not at 1.0 and so the API is known to be unstable, but considering how many people use Slate in production, it might be nice to label certain releases as potentially unstable for use as well.

In particular, the current set of releases that removed leaves probably had a higher than usual likelihood of being unstable. Another set of changes that will likely be unstable for a while is when we do the switch to immer.

What’s the expected behavior?

I wonder if even within our pre-1.0 releases there might be a way for us to indicate to the end-user that they may not wish to update to the new release on a production app.

I also feel like this might give people more confidence in using and upgrading Slate.

There are those of us who are on master (mainly contributors), others that will be at the latest published version (cutting edge developers) and those that are at stable (users that require a stable version of Slate in production).

[ianstormtaylor]

Hey folks, I appreciate the want for greater stability in Slate.

That said, I don’t think adding more process to the development cycle is going to be a viable solution, because it only increases the burden on the maintainer and leads to slower development cycles. While Slate is in beta I am specifically optimizing for speed of evolving the API towards our ideal target. Doing extra work like maintaining an extra LTS branch is unrealistic.

Instead, if your use case requires more stability than Slate has currently, the solution is to contribute your time in the form of well-designed tests. We’ve known that we need to have browser-level tests for much of the logic in slate-react, but we don’t have them yet. They would ideally catch things like drag-and-drop, copy-paste, selection handling breaking. The same goes for lower-level operation-based tests if those are where you need more stability. Pretty much any cause of instability can be linked to a specific area where tests can be improved.

[justinweiss]

In order to be effective, I think it has to involve more than just marking a version as stable / unstable. I’m in the process of moving from 0.33.x to master, and the bigger problem has been that there hasn’t been a version since 0.34.x that has been stable enough for us to stop on.

I hope that doesn’t sound harsh, because I absolutely don’t mean it that way! The improvements have been massive, and I’m so much happier with the code I can write with newer versions of Slate. Moving quickly has meant that we can still get big API improvements, and I wouldn’t want to give that up.

But I think that in order to make a stable / unstable split work, it would also need to involve a change in process. If you have to go to an unstable branch to fix a bug that’s fixable in stable, you’ll always have to use unstable. Instead, what if bugfixes went to a stable branch to make it more stable, and then those changes get merged into the unstable branch? That’s more or less how we’ve been working so far with the version we’re running in production – backporting bugfixes by cherry-picking when we can.

That would add more friction (and merge conflicts) than just marking a release, but would solve the problem more thoroughly. I don’t know if that would bring more pain than value at this stage of development, but if we were going to make a stable/unstable split, that’s what I would like to see.