Slate: Consider identifying unstable releases (mark as alpha?)

[thesunny]

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).

[jmoyers]

Though I'm not a long time user, I have been digging into slate over the past few days evaluating different rich text editors available on the market for my use case. I spent probably half that time identifying and narrowing down a few bugs that cropped up after simple extensions to the example code. Not sure if this is a direct result of the stability of the latest npm release, but it would definitely boost my confidence understanding what you as maintainers consider to be "safe." As a novice with the project, I'd be much more likely to stick to stable and then move to edge after getting more experience debugging slate issues.

[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.

[glebtv]

It would be really nice to have something like an LTS branch after fixing Android, and, probably, removing immutable :) Those are really two must-have things for me..
Currently using 0.46 in a medium-sized app and will not upgrade to 0.47 due to all plugins being broken and no notable user-side improvements..

[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.

[Slapbox]

@jmoyers it's a fast moving codebase. Your best bet is to reach for a minor version that's 2-3 behind the latest, and grab the latest patch version for that version. I think with the possible exception of a single minor version (pretty old now) the latest patch is always as stable as it gets.

I totally agree with you @ianstormtaylor. Tests are the best way to manage this without slowing things down until we reach 1.0.0.

[thesunny]

@ianstormtaylor

Hi Ian, FYI, the thread has gotten away from the original submission which was simpler. I feel like the original intent may still have value to you so as a reminder, the original idea is to identify releases that are more likely than usual to be unstable (e.g. because of an architectural change internally).

The cost is lower than what's being discussed:

• Just figure out a standard to identify. Could be odd/even sub-version numbers or an @alpha designation. Whenever we make a major architectural range, we mark it initially. I think it shouldn't take more than a few moment's thought.

We don't need to guarantee everything is working. There are just certain points where it is more likely than normal that we are introducing a bunch of bugs so it's kind of a buyer beware type of situation.

The benefit is two-fold:

• New users don't give up early because they run into showstopper bugs on first use
• Users that want to keep up-to-date but are running production apps can have a little more confidence about when to update

And that's it. It still may not be worth it but I want to make sure we evaluate the original option as well.

[dmitrizzle]

Perhaps we can ask on Slack and elsewhere which Slate versions do people prefer locking into (and build a 'stability graph')?

We should probably try and assign Slate version numbers to open and closed issues (i.e. opened in 0.4.0, closed in 0.4.1). Currently all issues are tracked against master or last release, but it's hard to pin point in which version they were discovered and which version has closed them. There are good references in PRs, but package versions would be a lot more useful for people who simply get the code from NPM.