Next branch release versioning

[mikeal]

This is a thread to discuss and eventually resolve the versioning of the next branch releases. The name of the channel they appear is out of scope.

This issue is descendent from #1997

Terms:

• CODENAME: an arbitrary english name given to a major version number. (Note that under some plans not every major version would get a CODENAME)
• Semver: Semantic versioning. Most notable parts are the definition of MAJOR and section 10 on "Build metadata" which defines what we refer to as the "alpha range."

There are currently two proposals:

The @domenic plan

• Under the @domenic plan CODENAMEs would be how we message each "handoff" from next to master when next is merged in to master as well as the eventual LTS lines.
• Semver would increase rapidly on next signaling breaking changes on that branch.
• This plan allows people regularly relying on next releases to depend on specific semver ranges and have assurances about breaking changes.

The @trevnorris plan

• CODENAMEs would be used solely for marketing, especially of the next releases.
• Every new release build would increment the alpha range for the major version above what is currently in master.
• LTS and master releases would be incrementing semver and may be referred to by their codename or their version while next releases would be seen as "Iridium 8" and then next week "Iridium 9" all the way until we're doing "Iridium Betas" and finally a big announcement that "Iridium is stable" and moves over to master. Under the hood "Iridium 8" is "3.0.0-alpha8".
• This plan simplifies the version increments for master and LTS and makes it easier to land breaking changes in the next branch.

[mikeal]

This comment is an edited version of a prior comment I made in the old release thread:

The argument here seems polarized but it's actually identical. Both @trevnorris and @domenic are arguing the same thing, that messaging and community building are harder for LTS or next depending on the route we take. A proposal to reduce that burden is to use codenames (either per major or per "blessed" major) and I think that we can soundly evaluate how effective that is for both cases to understand the tradeoffs.

I don't think there is a technical argument here but someone can correct me if I'm missing it. It's easier to reason about semver in both code and messaging but modules are, by and large, not restricted to any semver range of the platform.

Currently I find the @trevnorris plan more compelling. I think that it's easier to deal with the messaging issues in next than in LTS because of the makeup and size of each community.

This I think is key point: we expect people taking next releases to keep up to date with every bump in the channel, and we have an incentive to keep them from relying on an interim version because it's totally unsupported. We do not expect people using master releases to stay on the "channel" and adopt a major bump immediately, we expect some amount of time to upgrade and we are actively supporting their continued use of that major.

[mikeal]

We've been discussing this for a while now. Unless there are any objections I think we should bring this to a vote in the next TSC meeting.

[Fishrock123]

See #1997 (comment) & this gist: https://gist.github.com/trevnorris/7620a64b086e95271197

[domenic]

Since I'm going to miss the TC meeting on this, my thoughts and advice which I hope can be taken into account:

• I think it is critically important to have a fast-releasing (attempting to keep pace with V8) "io.js" release line.
• I think it is critically important that this release line be semantically versioned using major version numbers to denote the breaking changes. (In particular, I believe that using build or prerelease metadata relegates this release line to second class.)
• I think that it would be ideal if there were not two sets of release numbers that needed to be tracked by users, and that an equivalence could be drawn between io.js versions and Node.js versions without the use of a table. This is not critically important, but is something I believe with some conviction.
• The best solution to the above constraints in my opinion is thus to maintain a single set of shared version numbers between Node.js and io.js. This means Node.js will skip majors (like it is doing today from 0.x to 4?.x), and that some coordination will be needed to avoid overlap (like is being done today with 3.x/4?.0). I think that is an acceptable cost.

To reiterate, the first two points are the most important (the first in particular being important to the Chrome team). If we can ensure those then anything else is at least livable.

In the end I am not TC and can only offer my opinion. I thank everyone who has engaged with me on these points and taken the time to understand my perspective. My main hope is that if the vote goes a different direction, that it is because the TC has understood and rejected my arguments. I'd be very sad if I didn't communicate clearly.

Have fun everyone!