Release Candidates

[jasnell]

@jasnell: On the Node.js side, there is work ongoing to introduce a very short release candidate phase. We need to determine how that reconciles here. The Release Candidates are largely intended as a gating factor for Long Term Releases but there are a few best practices here to consider. Not sure how RC's jibe with the semver approach

@mikeal: I think RC releases are good for LTS branches but for current we're doing like 2 formal releases a week plus nightlies so it just doesn't mash up as well. As far as semver goes you can actually just do "0.12.5-rc1"

[mikeal]

To expand on this a bit: in io.js we've found that there's a limited number of "please test this" builds that you can do. For the community that wants to do testing on features prior to release we have the nightlies and there's talk of doing some kind of "Canary" build with the unstable v8 line it.

Also, because we have so many concurrent changes and reviews happening we can't wait some set amount of time before releasing, even a day. The last time @rvagg held up a release for a day the commit log in the release doubled overnight to a size we're not comfortable with.

That said, for LTS releases RCs would seem to make a lot of sense. A more stringent "certification" process would be prudent and putting out an RC is a good way to signal to other companies that they should run their own tests as well.

[Fishrock123]

Seems fine for LTS, but there isn't much reason to when you have nightlies and you release a "stable" (CI-passed) version like, once a week or so.

This probably ties into LTS strategies. it's probably best to not LTS every release, but rather have the LTS team pick specific releases to extend LTS support to.

[jasnell]

Yep.. I'm thinking about writing up a draft LTS strategy to help seed the creation of the LTS Working Group. What I'm currently thinking is that, similarly to how node.js works today, only even numbered minor releases would be up for LTS and only a handful of those per year. The "release candidates" would essentially be the patch levels leading up to the LTS release. For instance, suppose we have a post-convergence release v2.2 that the LTS WG decides will become an LTS release. v2.2.0 becomes the initial LTS Release Candidate. If bugs are found that need to be fixed or other additional changes come in, it could get bumped up to v2.2., v2.2.2, etc. Once the additional issues are resolved, the actual LTS Release itself might be v2.2.3 (for instance). At that point, a v2.2.3+LTS type tag would be created and things continue to march on. The next possible candidate for LTS release would be in the 2.4.x line.

The LTS branches would serve as checkpoints for critical bug and security fixes. If a security issue comes up, for instance, the policy would be to fix the issue in current + each of the LTS releases back to when the vulnerability first manifest. This obviously causes a challenge with the semantic versioning model in that a previously cut branch is not supposed to be modified without minting a new version... which will likely already have moved on. We can "abuse" the build metadata mechanism here. For instance, something like v2.2.3+LTS.20150404, v2.2.3+LTS.20150405, etc.

[Fishrock123]

only even numbered minor releases would be up for LTS

Can be either under semver. The whole even/odd thing only applies to 0.x (current node)

This obviously causes a challenge with the semantic versioning model in that a previously cut branch is not supposed to be modified without minting a new version

meh. I don't think there is an issue with us messaging we would be "breaking" that, for versioning sanity.

[Fishrock123]

Actually, it should probably be stated that we shouldn't really need LTS versions outside of majors. If we do semver anywhere near correctly the only difference between patch and minor is messaging to users about content, not about how that content will run.

I.e. minors should (as best as sane and possible) never break anything more than a patch could "break" (i.e. bugfixes)

As such, it's more useful to just message to people that minors are safe and the latest is to be used, and do LTS on majors.

[jasnell]

Assuming the semver strategy is correct and minors are always guaranteed to be additive, that would be fine. The one sticky area becomes security patches (of course) where a PR could change behavior in a non-backwards compatible way. For instance, if the last patch in the 2.x line is 2.3.5 and we have a new major 3.0 cut, then an security vulnerability comes up that requires an non-backwards compatible change in the 2.x line, for LTS we'd be required to push out a 2.4 that is not backwards compatible with 2.3.x, etc. As long as that's understood and documented, then setting the LTS goalposts at the major releases should be fine.

Perhaps a point in the policy that says once a new major has been cut, an older major release line can ONLY be modified for critical bugs and security vulnerabilities and that breaking changes can only be introduced when dealing with security vulnerabilities and that those must require a sem-minor bump? So if we're currently on 3.x and a security vulnerability in 2.x is found and the most recent change in 2.x is 2.2.5, then introducing a non-backwards compatible security fix would mandate a bump to 2.3.0.

[mikeal]

The best way to handle this is probably SHOULD NOT language rather than MUST NOT around only doing major version lines so that we leave the wiggle room necessary if a security fix were to cause a backward incompatible break.

[mhdawson]

I agree that given the minors may need to be incremented in an LTS line, then majors should be the LTS candidates. The only issue would be if they did not occur often enough but it seems more likely that it will be the reverse and there may be more major versions than we want to LTS. I also assume that if we get to a point and want an LTS we can use that as a justification for a major version bump anyway.

[Fishrock123]

The only issue would be if they did not occur often enough but it seems more likely that it will be the reverse and there may be more major versions than we want to LTS.

In part given that some v8 bumps may require majors, yes.

I also assume that if we get to a point and want an LTS we can use that as a justification for a major version bump anyway.

I do not understand; the current "LTS" would be on the current major, i.e., why would you cut a major to do support, when you could just use patch fixes / minors like what would already be happening?

[mhdawson]

I'm thinking the model will be that you pull a subset of all changes into the LTS releases. Therefore, if there were lots of non-bug fix/security changes, even though none of them forced a major bump you might still want a new LTS release in order to get those changes out to those using LTS releases.

[jasnell]

Let's walk through a scenario...

• master rolls over to 2.0.0
• the LTS WG decides that there will be a 2.0.x LTS Release. 2.0.x becomes the LTS Candidate (Milestone created).
• patches go into 2.0.x.
• a PR comes in that requires a semver-minor bump. At this point, a decision needs to be made, either: (a) the highest 2.0.x patch becomes the LTS Release or (b) the LTS Candidate is rolled over to 2.1.x. Specifically: the point at which the LTS WG declares the LTS Release ready depends on when the LTS WG determines that the goals for the LTS Release have been met. This can be at any Minor.Patch version.
• So let's assume master rolls into 2.1.x and the LTS WG decides to take the Minor bump, a few more patches come in and the LTS Release is cut at 2.1.15.
• Master keeps rolling through 2.x minor releases.
• The LTS WG can decide to declare a new LTS Release any any point, even within the 2.x release line. If, for instance, master rolls on to 2.5 with significant new API additions, the LTS WG could decide to cut a new LTS release on 2.5.x (it's not likely but it's possible).

The LTS WG is not required to cut an LTS Release on every Major or Minor bump. It's completely up to the LTS WG. It can choose to skip however many it wants.

[jasnell]

Crap... nevermind... forgot about my own suggestion on the security exception for minor bumps... that won't work with this... the other option is to force a semver-major bump with every LTS Release. So if the LTS WG declares that 2.1.15 is the LTS Release. The upside/downside of this is that it would likely force the LTS WG to be more conservative in how often it cuts an LTS Release.

As an aside, this is one particular area where semver kind of falls down: there is no accounting for maintenance of LTS checkpoints in the versioning stream. See semver/semver#17 for reference

[jasnell]

Using a post-release extension on the LTS Release version as described in semver/semver#17 may be the way to go actually. Doing so keeps us from having add exceptions to the versioning policy and allows post-release maintenance to happen. For instance, if the LTS is cut at 2.5.1 and post release fixes happen, the version would become something like 2.5.1~0.0.123 where everything after the ~ is in it's own major.minor.patch namespace. With this approach the LTS streams and master can continue to evolve without stepping on each other.

[mikeal]

why not "2.5.1-rc1" ?

it works in npm.

[jasnell]

I'm not all that concerned about the numbering of pre-release items so
whatever works there. It's the post release changes that are going to give
the most difficulty.
On Apr 6, 2015 5:34 PM, "Mikeal Rogers" [email protected] wrote:

why not "2.5.1-rc1" ?

it works in npm.

—
Reply to this email directly or view it on GitHub
#3 (comment).

[Fishrock123]

Let's walk through a scenario...

• master rolls over to 2.0.0
• the LTS WG decides that there will be a 2.0.x LTS Release. 2.0.x becomes the LTS Candidate (Milestone created).

Wait, what? Why would you choose the active branch after it has just rolled over?

Shouldn't it be:

• master goes from 1.x -> 2.x
• the LTS WG decides that there will be a 1.x.x LTS release
• (...)

the other option is to force a semver-major bump with every LTS Release

Please no, let the major bump itself in master organically.

I feel like anything requiring extra patch-metadata is becoming unnecessarily complex...

[jasnell]

Well it depends. Both approaches would work. In the approach I described, the stream works forward to the LTS Release, while in the approach you suggest, the LTS Release happens after the branch is rolled.

What I'm looking to achieve here is a process by which the LTS WG can cut an LTS Release organically at any point without impact on the versioning scheme. Sadly it's a non-trivial problem. I need to break for dinner now but will be taking another whack at this part later on tonight. It may take me a while, but eventually all the light bulbs light up and I'll come up with something that makes sense.