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.