Proposal: Release Process

[mikeal]

Several discussions and threads have made it clear that the existing release policy is not working for a lot of users and developers. At NodeConf Adventure we had a few sessions about this and, with more users than node core developers, we came to very different conclusions than we have in prior threads and TSC meetings.

First, I should lay out the different concerns the release process needs to satisfy.

• We need to take new versions of v8 in a timely manor.
  • We need to do real releases (not just nightlies) that are in use.
  • If we don't do this we fall too far behind the v8 cycle and can't collaborate effectively.
  • There's a growing contingent of users that want to adopt new language features and would like to have access to them on roughly the same schedule Chrome is releasing them.
• We need to release contributions in a timely and usable manor.
  • The vast majority of contributions are not breaking changes but patches and feature additions.
  • The current schedule for breaking native addons means that most contributions are being released in a version that is not usable by the vast majority of users because the timeline for native addons being updated is longer than our major release cycle.
  • We need an incubation phase for these releases to validate there are no breaking changes. The number of breaks we've had in CURRENT leads people to avoid it and actively advocate that people don't run it.
• We need a release line that is extra stable and a way to signal when a breaking release in this line is ready to be adopted. Actual quote: "I won't run a release line that hasn't been in wide use for a year."
• We need LTS releases and an LTS guarantee that is achievable. On a 5 year support timeline this means that we have to support (major releases per year * 5). If we do a six week major cycle that means 43 support lines -- that is not achievable.

One thing that should be clear by now is that users who wish to "adopt new JS language features" cannot rely on native addons. Those two priorities are simply incompatible at this time. We have good ideas about how to improve this in the future but we aren't there yet and v8 is going to break native addons each release for the foreseeable future.

Here's my proposal, laid out by branch.

master branch

Master should release on the same cycle and frequency we have now. Releases should appear in the BETA channel. If a critical bug or regression is found the PR fixing it should be tagged and merged.

incubation period

Master releases appear in the beta channel. If a critical bug is not tagged and merged within the incubation period the last release older than the incubation period is moved to the CURRENT channel.

next branch

Multiple updates to v8 should appear in the next branch. Relatively frequent releases should appear in the CANARY channel with increasing alpha version numbers (i.e. 3.0.0-alpha19). Any breaking changes being considered should also appear in the next branch.

Approximately once a year the next branch should be merged in to master and all the appropriate version numbers kicked over. This is at the discretion of the TSC but should likely happen when there is a good level of confidence in the stability of v8.

LTS branches

When next merges in to master we create a new branch for that major release's LTS line (as we do today).

The STABLE channel contains that latest LTS release of the latest major version under LTS.

Website Mockup

---------------------------------------------
|         |         |        |              |
| STABLE  | CURRENT |  BETA  |    CANARY    |
| 0.10.99 | 2.89.4  | 2.91.2 | 3.0 Alpha 14 |
|         |         |        |              |
---------------------------------------------

User Expectations

Developers who want to adopt new features will follow the CANARY channel. We can do evangelism around major events in the alpha cycle based on features that land from v8 or other major changes that might land. We should expect this section of the community to slowly move away from any dependence on native modules.

Most people involved in regular core development will sit on the BETA channel. Large institutions and popular open source projects should point their test automation at the BETA channel and encourage their users to adopt the CURRENT channel. The CURRENT major lives for about a year, which is about how long it takes for the entire native ecosystem to "catch up."

Larger production users should track STABLE. When upgrading to a new major release of STABLE the expectation is that all modules will work and have ample testing over the year of being in the CURRENT channel.

Current Versions, Branding and the Convergence.

If we adopt this release process we should scrap our current convergence plan.

Features from 0.12 should converge against io.js master. master should remain at 2.x. No breaking changes can be converged in master and should instead be done on next.

All release lines should rename to "node.js" as soon as possible and development should move to nodejs/node as soon as convergence on master is complete.

• STABLE is 0.10.x
• CURRENT and BETA are 2.x
• CANARY is 3.x

I don't know what this means for LTS of node.js 0.12 and io.js 1.x. Maybe we do it because it sends the right message but I don't think that either of these release lines should land in STABLE and we should skip over them because neither will end up going through a year in the CURRENT channel which I believe should be a requirement for this channel.

[ahmadnassri]

I'm not certain whether LTS should or shouldn't be part of the release process considerations? that is to say, there doesn't seem to be any reasoning to limit a "release process" design with identifying LTS candidates.

you could in theory identify any major release as candidate for LTS, regardless of numbering or timing, that could be determined in a separate policy / process.

I can also see there's a working group discussing LTS already, so some more clarity hopefully could surface from that side.

[mikeal]

you could in theory identify any major release as candidate for LTS, regardless of numbering or timing, that could be determined in a separate policy / process.

This is what I had thought we could do a few months back but, unfortunately, it isn't quite practical. Users look for an LTS guarantee in anything you ask them to adopt and we are certainly asking people to adopt CURRENT. If you do releases that you ask people to adopt and then drop support shortly after you don't end up accomplishing what LTS is designed to do: create a feeling of safety around adoption of the platform.

[chrisdickinson]

My initial reaction: I'm broadly in favor of this. We might consider changing the names of STABLE vs. CURRENT since they have the potential to direct audiences to the wrong place (namely, we want enterprise customers to choose "STABLE", we want users to choose "CURRENT.") That's a naming quibble, though.

I'm going to stew on this a bit more (especially the convergence bits), but for now, great work!

[mikeal]

@chrisdickinson I sort of stole the naming convention from FreeBSD for CURRENT and STABLE. It seems to work for them but our community is quite different so we may need to use something else.

Also, keep in mind that module authors also need a timeline for dropping support of old releases in their current development so we need something that conveys an expectation to module authors that they should still be actively supporting and testing against whatever we end up calling the STABLE channel.

[mscdex]

I also think that having both "Current" and "Stable" labels as separate things can be confusing, since it's possible to have a "current" stable version and an old stable version (e.g. v0.10.38 vs v0.10.0 or even v0.8.xx). I'm not sure what name(s) would be better though.

[chrisdickinson]

@mikeal I was (a bit cheekily, perhaps) considering calling the "STABLE" channel the "ENTERPRISE" channel. Plus, this lets us start building up a space-/sf-themed set of channels (io.js, enterprise.js, etc, etc. – just need ones for "beta" and "current") 👽

[mikeal]

considering calling the "STABLE" channel the "ENTERPRISE"

I'm not opposed to this.

set of channels (io.js, enterprise.js, etc)

Perhaps some time in the future we can call one io.js but, at the moment, calling one of them io.js is deeply confusing :)

[ahmadnassri]

you could in theory identify any major release as candidate for LTS, regardless of numbering or timing, that could be determined in a separate policy / process.

This is what I had thought we could do a few months back but, unfortunately, it isn't quite practical. Users look for an LTS guarantee in anything you ask them to adopt and we are certainly asking people to adopt CURRENT. If you do releases that you ask people to adopt and then drop support shortly after you don't end up accomplishing what LTS is designed to do: create a feeling of safety around adoption of the platform.

I don't disagree with that statement, I guess all I'm saying is: you can create a separate policy for tagging a major release as LTS, regardless of what process you use to issue releases.

e.g. the LTS policy can be as simple as: "Every second major release is an LTS release", so: (major releases per year / 2).

or perhaps tie LTS with yearly quarters: 4 LTS releases per year * 5 years = 20.

[mscdex]

Does anyone have any opinions on having an LTS release schedule like that of Ubuntu's (currently an LTS release every 2 years)?

[Fishrock123]

We need LTS releases and an LTS guarantee that is achievable. On a 5 year support timeline this means that we have to support (major releases per year * 5). If we do a six week major cycle that means 43 support lines -- that is not achievable.

I think the current LTS proposals are widely misunderstood. To be fair, they are also clumsy and confusing.

The previous idea would be to widely message that only some lines will be tagged for LTS.

[mikeal]

I think the current LTS proposals are widely misunderstood. To be fair, they are also clumsy and confusing.

I think this is mostly because we have been writing them in isolation from the actual release process, which we keep changing and then expecting the LTS folks to catch up.

At various points we've externalized LTS needs by saying "the LTS WG will handle that" so we don't have to consider them in the regular release process and effectively treated the LTS WG like a dumping ground for stability concerns. Stability concerns must be a part of the regular process and the LTS WG can find the best way to coordinate the effort required to do STABLE and LTS releases once the regular process, which appreciates the time and effort required to maintain a major release line, shifts the major release cycle.

[subfuzion]

I think we should avoid conflating STABLE with LTS. If we consider the Ubuntu community's definition of LTS, it is enterprise focused and not a feature-based / cutting edge release.

Using @mikeal's website mockup, it would look like this.

 -------------------------------------------
|         |         |        |              |
|   LTS   | CURRENT |  BETA  |    CANARY    |
| 0.10.99 | 2.89.4  | 2.91.2 | 3.0 Alpha 14 |
|         |         |        |              |
 -------------------------------------------

I agree with @mikeal that CURRENT needs to be stable. There is no point in having current releases perceived as beta releases that organizations are afraid to adopt. I like the idea of an incubation period for releases before promoting them to the next channel.

I disagree with the need to indicated a stable line that has been in wide use for a year. LTS provides a strong stability guarantee for those who need it. Just because a release line is a year old doesn't mean it conveys any guarantee about how widely adopted and therefore vetted it was, particularly given the rapid rate of io.js releases.

An organization that wants to hold off on adopting current releases for a period of time as a matter of policy can certainly do so, but labeling an older release as stable is potentially misleading. Especially with io.js' adoption of semantic versioning, the decision whether to adopt current, remain a minor (or major) version behind, or stick with LTS should be enough for an organization.

[rvagg]

(commenting without having read the bulk of the comments yet, sorry)

Can we please remove discussion of LTS from this thread, there is almost zero overlap between the proposal(s) here for LTS and the work that's been happening in the LTS WG (on GitHub exclusively so far). This is a complex topic and requires significant commitment from certain parties that have a stronger interest in LTS than most users (as nice as it sounds to have "stability", it's not the new hotness that everyone really wants to work on, LTS work is going to be a hard, borning, tedious slog that will likely be supported primarily by corporate players with a commercial interest in this area).

So rather than allowing this discussion get into fantasy-land and therefore go nowhere can we please, please, please remove LTS from the scope and focus on other aspects of "release" instead. If you are really interested in LTS (and can realistically contribute) then pipe up in the LTS WG--as much as everyone wants to talk about it, it's been difficult to get people who will do the hard work together thus far but we'll be trying again in the coming weeks.

[subfuzion]

@rvagg, Confining LTS discussion to the LTS WG makes sense (and I completely agree with LTS being tedious -- and likely supported primarily by commercially interested, corporate players and therefore needing separate consideration).

With that being the case, I also understand the need to indicate a "stable" channel as initially presented in @mikeal's mockup. Although I still chafe at the word, there's no doubt in my mind that 0.10.* represents a pretty stable version of Node at this point. I'm not sure at which point I began to think of it as stable, but I suppose it was at some time after it had been been out for a while and gone through a number of updates. So I guess that brings me right back to the original then:

 -------------------------------------------
|         |         |        |              |
| STABLE  | CURRENT |  BETA  |    CANARY    |
| 0.10.99 | 2.89.4  | 2.91.2 | 3.0 Alpha 14 |
|         |         |        |              |
 -------------------------------------------

I guess what I hate about "stable" is that it will be used by so many people as a reason for not using current. Maybe we could call it VENERABLE ;)

[mikeal]

Some notes from a recent conversation with @rvagg on IRC.

• While we figure out this whole canary/beta/current thing we should stay away from discussing the LTS process. For the time being 0.10.x is the blessed LTS and the process for maintaining and releasing it can go on while we figure this out.
• Current, next is a bit stale so if we're talking about persisting it for a while we'll need to come up with a good way to keep it up to date with what lands in master
  • Possibly automate a rebase.
  • Possibly do time based releases to ensure we don't wait too long between.

[subfuzion]

@mikeal, when you say:

• We need to take new versions of v8 in a timely manor.
  • We need to do real releases (not just nightlies) that are in use.

what do you mean by "we need to do real releases"? Are you referring to the v8 releases?

And when you say:

Master releases appear in the beta channel. If a critical bug is not tagged and merged within the incubation period the last release older than the incubation period is moved to the CURRENT channel.

this means that if a critical bug IS tagged and merged within the incubation period then the previous release is NOT moved to the CURRENT channel and the incubation period is extended by the new BETA fix, correct?

Any thoughts on a reasonable incubation period? 10 days? 30 days?

[benjamingr]

• 1000 for this. The way the current release process works is broken and this would go a long way to fix it. I think that time bounds need to be established so stable never falls too far back - we don't want a 0.10 and 0.11 line.

[mikeal]

what do you mean by "we need to do real releases"? Are you referring to the v8 releases?

Real releases of Node. It's hard to build a community round nightlies, having releases you can point people at and get them excited about a feature landing help, which is why I think that Alphas are a good idea.

Any thoughts on a reasonable incubation period? 10 days? 30 days?

The time that was kicked around at Adventure was 2 weeks. I think we can start there and iterate over time as we learn.

[Fishrock123]

The time that was kicked around at Adventure was 2 weeks. I think we can start there and iterate over time as we learn.

I'd like to try starting with one week ala npm. I think it was mostly you kicking around the 2 week thing. :)

[mikeal]

I'd like to try starting with one week ala npm. I think it was mostly you kicking around the 2 week thing. :)

1 week sounds even better.

[aredridel]

I think with the pace of things, 1 week makes a lot of sense.

[Fishrock123]

If we adopt this release process we should scrap our current convergence plan.

Features from 0.12 should converge against io.js master. master should remain at 2.x. No breaking changes can be converged in master and should instead be done on next.

All release lines should rename to "node.js" as soon as possible and development should move to nodejs/node as soon as convergence on master is complete.

@mikeal this is confusing, why?

[mikeal]

@mikeal this is confusing, why?

The current plan calls for us to merge everything for the "next major release" but if we're now saying that we might wait close to a year before a new major we would want to begin putting out new converged node.js releases under the CURRENT channel instead.

[domenic]

A year between new major versions makes no sense. A year between new LTS releases seems fine. Let's be sure to differentiate.

[mikeal]

A year between new major versions makes no sense.

That's about how long it takes for the native module ecosystem to catch up, so it sort of does make sense -- assuming that we have a channel where v8 is adopted on a 6 week cycle and used outside of the major cycle (Alpha releases in the CANARY channel).

[domenic]

Firefox is a good example here. Every 7 versions is a LTS release. But major version bumps every 6 weeks. That's a reasonable model and one we should be following.

[mikeal]

Every 7 versions is a LTS release.

Each one of those 7 releases doesn't break 30% of the websites it tries to render. Those aren't breaking releases -- our problem is that we have major releases with large breaking changes to native modules.

[domenic]

assuming that we have a channel where v8 is adopted on a 6 week cycle and used outside of the major cycle (Alpha releases in the CANARY channel).

Relegating up-to-date, security-bugs-fixed JS VMs to CANARY is not tenable. We should not advertise insecure releases. We should advertise LTS, which gets security work done by the LTS community, and we should advertise current major, which is secure and usable.

our problem is that we have major releases with large breaking changes to native modules.

Yes, that is the definition of major release.

[Fishrock123]

Most of these concern the human aspect of development. Only a few technical notes. Regardless, I believe these are important and worth considering.

I agree.

This versioning is a mis-conceptualization of what is really happening. We will have releases of next, but breakage in a development branch shouldn't be reflected in a stable release. The only advantage is we get to see how many times the development branch had breaking releases. It doesn't seem a good enough reason to warrant forcing what's happening on next into master.

Though I also disagree that next should only have a breaking release every six weeks. It could be frustrating for a dev who implements a new feature, for a development branch, and it isn't released for up to 6 weeks. The logistics are also complicated. We're going to "maintain" a release branch from the development branch for 6 weeks, just to merge it back in? Or all fixes that land on the development release branch will also have to be cherry-picked onto the development development branch.

So, there's a little not-so-little problem to solve then. How are we going to version it so that people that want to depend on it or support it alongside "regular" releases, can do so? For example, a package.json's versions field.

I suppose one could stick this all in patch metadata, but that's pretty second class, is there a better way? Can we do like 3-pre-X.Y.Z? I'm not familiar enough with how node-semver works to know..

[cjihrig]

Just a crazy (and half baked) idea, but I figured I'd throw it out there. What if the release number was LTS.major.minor.patch, so LTS releases were predictable, and semver was started from scratch in each new LTS release.

[Fishrock123]

@cjihrig I think it would have to be STABLE.x.y.z, but since the major there is never bumped once in stable... why bother?

[cjihrig]

@Fishrock123 like I said, this was only half baked. My idea would allow development releases to continue on master, but wouldn't work for the LTS team.

[trevnorris]

Another half-baked idea. On next just increment the patch (since breaking changes should be expected anyway). So it starts at 3.0.0, then 3.0.1, etc. When it lands on master it becomes 3.1.0.

[rvagg]

I think the proposal as it stands now should be fairly stable although it would depend on how next/canary is handled.

If we have a 6-monthly next -> master merge and a yearly LTS then we should end up with every LTS taking over every second major version number, at some arbitrary minor and patch. If next is simply x.y.z-alpha.N, regarless of what V8 is included in it, then master would simply be a major version increment every merge, i.e. every 6 months. Then at the end of every second master cycle LTS would take over.

Anyway, this still seems like bikeshedding to me, perhaps you could open an issue @ https://github.com/nodejs/LTS/ and come along to the next LTS meeting next week to hash this out. We've been reaching out to companies that this would affect and haven't had any feedback on version number concern thus far but perhaps if it's raised as a separate issue over @ LTS it might collect some opinions.

[domenic]

So the next releases (which, remember, are going to be marketed as "io.js" or "Node.js Future" or something) don't get proper semantic version numbers? Just relagated to the alpha range?

That's very disappointing.

next is not a development branch for master. It's the fast-paced io.js-style stream for people and libraries (like jsdom, for example) that want to adopt and use new features. It deserves first-class treatment.

[rvagg]

@domenic I'm not asserting an opinion on next, just riffing off the OP where @mikeal proposed that. I personally don't have a hangup on proper versioning all the way up to next and making that flow down to master and LTS. I believe the most important thing for LTS is the predictability around timing of release. Codenames may also help.

[trevnorris]

this still seems like bikeshedding to me

Thing I mainly care about is having consistently incrementing majors on LTS. Which extends to master because LTS will inherit that. The majors don't even have to be sequential.

the next releases (which, remember, are going to be marketed as "io.js" or "Node.js Future" or something

Then not forcing master to inherit next's major shouldn't be a problem. It would be even stranger if master followed after something that wasn't even released under the same name.

And if we are going to do the whole next have its own release branch thing then I'll have to insist it follows its own release policies. Because that basically means a patch for master has to land in 3 places. That'll get hairy fast, because as amazing as our automation may be human intervention will still be required.

That's very disappointing.

I'm sorry? I tried to be very clear why not having consistent incremental majors isn't practical in terms of user experience, but I have yet to see a rebuttal of why making sure we propagate the all powerful semver is more important.

Also I take issue with the fact we're releasing next around V8's schedule. Like it will ever be the only breaking change. But that's for a different discussion.

the most important thing for LTS is the predictability around timing of release.

Before any dismissal of not having consistent majors I would like my discussion points addressed. Which includes issues around using code names for releases.

[domenic]

Then not forcing master to inherit next's major shouldn't be a problem.

It is definitely a problem. Having two release lines with two separate version number trains, which you need a table to correspond, is horrible, especially for developers who want to program constraints or similar. Having next and master share an increasing set of release numbers is done for the same reason we're not just releasing "Node.js 1.0" as the first converged release, but instead going with "whatever io.js is on plus one."

Here is a concrete example:

• In month n, Node.js 4.0 is released
• In month n + 2, io.js 5.0 is released
• io.js continues with breaking releases every once in a while. Eventually some awesome stuff gets in to version 6.1.
• A developer wants to use this awesome functionality from 6.1+ in his module awesomestuff. He sets a constraint in his docs/package.json/runtime checks/whatever.
• In month n + 6, io.js is at 7.2.1, and Node.js is at 4.7.2. Node.js is ready to do a new major release.
  • In your world, Node.js releases 5.0.0. Sad times! awesomestuff still does not work. The awesomestuff developer needs to say "if you're using Node.js, use 5.0+. If you're using io.js, use 6.1+." The awesomestuff developer not only needs to update his docs, but also any package.json constraints, or dynamic checks. Any tooling based around enforcing such constraints (maybe npm, maybe others) needs to branch to accomodate the two different constraint types. Any documentation on the converged project's website needs to include: "this feature is present since: Node.js 5.0+, io.js 6.1+"
  • In my world, Node.js releases 7.2.1. Everything works! awesomestuff automatically works in Node.js now, not just io.js. The developer might remove a sentence from his docs like "only io.js has released this version yet; wait for the next major Node.js release, estimated in month n + 6, if you want to use awesomestuff in Node.js." All tooling can deal with only a single set of release numbers. All docs can just reference a single version constraints. Nobody needs to put together a big table of correspondence.

but I have yet to see a rebuttal of why making sure we propagate the all powerful semver is more important.

Hopefully the above does that.

[jasnell]

I think I'm starting to come around to @trevnorris' point of view on this. Consider:

If next and master share a common semver, we risk version collisions when we merge from next to master unless we either (a) artificially bump the major in next following the merge, (b) time the merge to coincide with the major bump or (c) time the major bump to coincide with the merge.

Bad:

Better:

Of the three options, (a) means bumping without corresponding changes which violates the semver model, (b) means unpredictable timing which goes against the LTS stability requirements, and (c) means holding major changes until the scheduled merge time. (c) is likely the least bad option.

However, this process also means that absolutely no major bumps can occur in master independent of the merge from next, otherwise we end up stepping all over next. I'm not convinced that we want that. next is intended for really big changes, what if all we want to do is change the default cipher list (for instance), I should not have to wait six months for that to land in master

Bad:

This is not a new problem. The version is a shared resource that needs to be synchronized across multiple threads. Some level of synchronization and locking is required in order for it to work. Synchronization means at least someone is going to be unhappy at some point in the process, either by having to wait to have their stuff land, or by artificially and purposefully diverging from semver.

We can avoid this by allowing next and master to have independent versions. However, this introduces the need to be able to reconcile which version of next maps to which version of master and vice versa. We ought to be able to achieve that fairly easily using tags, but it does mean developers have more to keep track of.

Obviously there are also merges from master into next that aren't being captured in these images but those would be similarly tagged (e.g. tagging a next release with tag:master-v2.4.3, etc). To make it a bit easier for users/developers, we can include the tags in the process.release metadata that @rvagg is proposing in #2154:

$ ./node -pe process.release
{
  name: 'nodejs',
  tag: ['next-v4.3.2'],
  ...
}

Yes, this introduces more overhead as @domenic illustrates, but it allows the next and master streams to evolve without blocking or stepping on each other, allows more predictable semver bumps in master addressing some of the concerns @trevnorris is highlighting (with some notable exceptions), and allows for the regular timing of LTS releases.

There are downsides to any of the approaches we choose, but allowing next and master to have their own versions seems to be the least bad approach.

[domenic]

what if all we want to do is change the default cipher list (for instance), I should not have to wait six months for that to land in master

You totally should. It's a breaking change, and we said no breaking changes in master more frequent than every six months.

---

Overall I think your (a), (b), and (c) are not really bad at all. We generally have plenty of breaking changes waiting that can help with (c). The timing on the next -> master merge is probably somewhat flexible (on the order of days or maybe a week), allowing (b) on ocassion. And we might fall back to (a) rarely, but even that's fine per semver spec.

[jasnell]

@domenic ... ok, but allowing next and master to have different versions does not cause problems in your user story above [https://github.com//issues/1997#issuecomment-122002191]. Specifically:

• In month n, master 4.0 is released
• In month n + 2, next 5.0 is released
• next continues with breaking releases every once in a while. Eventually some awesome stuff gets in to version 6.1.
• A developer wants to use this awesome functionality from 6.1+ in his module awesomestuff.
• In month n + 6, next is at 7.2.1, and master is at 4.7.2. Node.js is ready to do a new major release.
• master merges from next and bumps to 5.0.0, which is tagged as being equivalent to next version 6.1.1
• At this point, the awesomestuff module should work with no problem in master version 5.0.0, yes, the developer may need to do a bit more work to document that fact but there are ways of easing that pain (for instance, npm could use the equivalency tags to automatically map out those connections). To be honest, developers building on an unstable branch need to expect a bit of pain anyway.

Also, being forced to wait six months to land breaking changes in master just isn't going to work if that breaking change happens to be part of a critical security fix. It would make absolutely no sense for us to land such changes in LTS and next but not land those in our stable master until potentially months later.

[domenic]

I mean, it causes all the problems of assuming people build an ecosystem and tools around these tags, instead of doing simple version comparisons.

[jasnell]

As I said, there are downsides to each of the proposed options. We aren't going to avoid that and I doubt we're going to come to a perfect solution. In my opinion tho, separating the versioning and leveraging the equivalency tags just seems like the least bad approach.

[mikeal]

Thing I mainly care about is having consistently incrementing majors on LTS. Which extends to master because LTS will inherit that. The majors don't even have to be sequential.

The only way to do this while maintaining proper semver is to stay in the alpha range for next releases. We should probably stop considering any other way to accomplish this because, for all the downsides staying in alpha might cause, they are smaller than the complications involved in creating new non-semver versioning semantics.

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.

Ok, imagine we're using codenames for each of these lines.

Under the @domenic plan those codenames would be how we message each "handoff" from next to master as well as the eventual LTS lines. Semver would increase rapidly on next signaling breaking changes on that branch.

Under the @trevnorris plan the codenames would be used solely for marketing, especially of the next releases. LTS and master releases would be incrementing semver and may be referred to by their codename or their version but 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".

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]

Ok, time to close this issue. PRs and Issues have been filed for the resolved and unresolved parts of this thread:

• The points we have a consensus on are in this PR: Updating with section about next branch releases. dev-policy#74
• Branding Release Channels
• Next branch release versioning

[Fishrock123]

FWIW @nodejs/lts discussed this yesterday and the plan is to have @rvagg and @trevnorris make an updated proposal to discuss / approve this TSC meeting. There are some bits in this currently that do not work well with git.

[mikeal]

Does any of that contradict what is in nodejs/dev-policy#74 ?