Slate: Proposal: @next releases

[thesunny]

The following is a proposal for introducing @next releases to Slate.

Please "thumbs up" to show approval and "thumbs down" to show disapproval.

There are two important issues that affect Slate releases:

1. The Slate packages have been releasing slowly. One of the reasons is that due to the complexity of the editor, it is difficult to be certain that a release won't introduce bugs. Although there are unit tests, Slate React is difficult to test reliably due to the number of platforms it must work on and due to the platform specific bugs it must work around. Due to these complexities, the maintainers including myself have been slow to accept new PRs.

2. It is difficult to tell known good releases from less stable releases. In the past, we have had Slate releases where some versions are known to be more stable than others; however, it is difficult to discern this information. Basically, you have to ask around to find out which are the more stable releases.

The proposal is to introduce @next releases.

While the goal would be that @next releases should be thought of to be bug free, the expectation is that these versions are less stable and may have introduced unknown bugs into them. The @next releases are ideal as a proving ground for adding more difficult to implement features like advanced TypeScript support.

Next steps:

• I think this can be implemented more or less immediately by either @ianstormtaylor or @CameronAckermanSEL. I think Ian is fairly busy these days as his company Segment was purchased recently. I imagine there is a lot going on. It may fall to Cameron to get this moving. It would be nice to have some approval from Ian on moving this forward although I don't know that this is strictly necessary since it won't affect regular releases.
• I'd be happy to setup the @next releases myself (potentially to include the TypeScript PR we have been working on) but I would need to get npm publish permissions which I currently do not have.

[SmilinBrian]

Can someone explain what @next release means in practice?
I feel like I am supposed to have used some product/service or read some article about best practices that I have not read, so it's hard to say if this is a great idea or not.

[bryanph]

A slightly easier solution for now might be to mark the "known stable" versions as "stable" with a tag for example because to know whether a version is stable or not usually takes a couple of weeks after the release is made. In general I think we shouldn't be too afraid to introduce new bugs with the changes we make. If they do get introduced we can add a test that covers that particular case to make sure it doesn't come back and fix the bug as soon as possible. If we're too afraid to make changes then more of us will simply end up forking which would be a shame because we would miss out on many valuable PRs.

[thesunny]

Reposting from a comment in Slate for people that aren't following there...

So apologies for taking a while on this. I’ve done research on @next releases and here’s my thoughts. I wanted to put them out here for feedback before I go ahead.

For some background, the way that npm works underneath is that when you publish, if you don’t specify a tag, it defaults to @latest.

Whenever you add a package to your project, by default, it grabs the @latest version. It does this quietly so you’re never really aware of the @latest tag but it’s there.

When we publish using an @next tag, the next version has a version number (just like @latest) but even if the @next version number is the highest, the @latest tag remains the default. If we explicitly ask for the version with the @next, that is when we get the @next versions.

My recommendation is that we make changes into the main branch and not into a separate next branch.

The reason for this is as follows

(a) We can more easily keep consistency with version numbers as npm defaults to incrementing them each time we release but they may interlace into each other if we are publishing from two separate branches.

(b) I think by default, we want to always be merging PRs into the most current version. If there is an @next version, we should be merging into that version, not the last @latest version. If we have separate branches, there isn’t a single place to go to merge. You kind of have to check around before you know. That is, if there is an @next branch, you’d have to make sure to merge into that instead of main. With a single main branch, you know that you are always working on the currently being worked on version.

So one worry about having an @next version is that we may need to make updates to the stable version at @latest. For this reason, I think we should simply make sure we bump to the next minor (or major) version at a next release which makes sense anyways.

In the (hopefully) rare cases where we need to patch because the @next release is long lived and not stable, it’s at that point that we create a patch branch. I think this makes more sense because having to patch an older version should be the exception, while merging into a @next version if there is one should be the default.

[thesunny]

We have @next releases now. To use them, use yarn add slate@next and yarn add slate-react@next or specify the version number manually.