Repository navigation
Release Cycle Proposal #168
Description
Activity
While I don't have much of a dog in this race, I much prefer a longer cadence. More lead time for the library developers generally means a higher degree of stability for what is generally available. So 👍 to a 6 week release cadence, rather than weekly.
The "train" is how I assumed things were going to run anyway. Given the TC member's track record on backwards compatibility, I say release small, release often. Try 1 week and see how it goes.
Just a quick note about a difference between browsers and us: as of a few years ago, most browser vendors don't ship bugfix releases for older versions. I suspect that we will. Also, browsers have an auto-updater that forces nearly all their users to upgrade, we don't have that.
We also have some natural "buckets," those being semver major, minor, and patch. What I suspect will need to happen is patch releases for every minor for 3-6 months and patch releases for every major for at least a few years. That needs to be factored in, we don't get to replace the version of Node for the majority of our users overnight the way the browser vendors do. But, this is all just speculation.
I think that all of this is very premature. We need nightly builds before we can talk about this kind of cadence, and we need to see a real release before we start talking about all these patch releases.
We need to start getting something out every week so that we can evaluate how it's going and improve the process from there. While I appreciate the sentiment behind threads like this they are based on a lot of assumptions that may or may not be true and we won't know if they hold until we see some traction.
Let's just get stuff out and iterate and stop planning prematurely.
@mikeal You are definitely correct in that we can't force an upgrade, which means how, why, and when major/minor version updates happen is a big concern. But I think that is different from this proposal.
The mentioned natural buckets make good final GA targets. If we end up with multiple GA targets, a train system like this would be meant to deal with the fastest updated bucket.
The primary concern of this proposal is the minimum time before, and in what stages, things move from being merged to being included in a full generally available release. Whether nightly is actually nightly or is a weekly build or anything else at the start of the train is not really a concern of this proposal.
Regarding it being too early to discuss this, @bnoordhuis asked me to write up a proposal after a discussion on IRC. I'm not the only one with concerns in this area. I want to make sure those concerns are addressed before weekly GA releases start happening implicitly, codifying what could be painful for us in the community.
Good discussion about this in the TC meeting today, I'd recommend seeing the video as the minutes are unlikely to contain all of the nuance of what went down. The agreement (as expected I think) was that this is still too premature but that everybody agrees that io.js releases need stability, predictability, decent lead-time but also need to be more frequent.
See #178 for TC minutes and link to video.
I really like how Mozilla has been documenting their release cycles. As per https://developer.mozilla.org/en-US/Firefox/Releases clicking on an upcoming version (like v36) provides a description of when it will be production released, the "stage" that version is in (beta/alpha/etc.), and a detailed list of the upcoming changes/additions, including those which might be behind a feature flag (or are finally being promoted from a flag, in some cases.)
As io.js works to deprecate some old APIs, introduce new V8 features, ES6 language additions and generally improve the core functionality, it would be great to have a similar structure of documentation to refer to. It also helps people to know what they can help test against, especially with regard to bleeding edge API.
Edit: added the second paragraph
A good compromise between the Train model and long-term stability is additional ESR releases (just like Mozilla does for Gecko/Firefox): Every
Xreleases, this release is maintained forX+1orX+2releases (providing security and serious-bug fixes). For the 6 week Train model andX=7, this will amount to ~ 1 year support of one ESR version with 1-2 (ESR release) version overlap (more if you consider pre-release channels).Discuss in #630
Context
Whenever the topic of release comes up, there will always be people on both sides. One side is looking for stability, other side looking to get features and bug fixes as fast as possible. Both sides have a part in common, that is predictability of release. Since we can all agree that predictability is important, we'll move forward assuming that a release schedule is a good idea.
Release Promotion
The next part to decide is how a release gets promoted to be a full generally available release. This part has contention, but what I'd like to propose is the same system as Chrome, Firefox, and now Rust. The style is called a train system. Every release cycle worth of time, the current beta is promoted to release, the current alpha is promoted to beta, and the current nightly is promoted to alpha.
This system allows users to run their tests against nightly, see when something breaks and know how long they have to fix it before a release happens. Not only that, they can canary and report problems upstream before the release is promoted further. Sometimes the discovery of where the bug/problem lies takes a while. Having the train means they can test against alpha while digging in, get things fixed, and have the beta be a theoretically 100% stable release preview. Obviously sometimes fixes also go into beta, but that should be a rare release blocking problem.
The only type of changes that would be accepted into the alpha and beta releases are fixes for regressions. This prevents other types of fixes from skipping the cycle and causing instability.
I can see stripping this down to just nightly, next, and release. Instead of the full nightly/alpha/beta/release. But having some sort of train system will be important for many of us who implement libraries.
Cycle Duration
We are in a state of frustration right now because Node 0.12 is not out and has taken longer than many of us would have liked. I bring this up as the currenly weekly release feels like an overaction in the opposite direction to me. My proposal would be 6 weeks, just like the above mentioned projects (Chrome, Firefox, Rust). This will be the contention point between the stability camp and the release all the time camp.
This gives plenty of time for people who have APIs tightly coupled with core APIs to react to any changes coming down the pipe. It does mean 12-18 weeks before a feature or bugfix makes it into a GA release, but it gives us time to work out any kinks that may have happened with the feature/fix. I'd be hesitant to allow this duration get lower than 4 weeks between nightly and release. This is to give library authors a definite chance to keep up without feeling like they are on a high paced treadmill.
Side effect of this is the ability of node to stagger its releases with Chrome. By releasing a week or two after Chrome, we get the ability to absorb new versions of v8 as they come, as well as getting fixes upstreamed before they make it into a full Chrome release. I consider this a win-win benefit.
Caveats
In both Chrome and Firefox, security fixes and fixes for sufficently bad bugs can skip ahead on the train. This is something that would likely need TC approval to happen. No one is advocating for leaving insecure versions of node in the wild on purpose.
Outside of scope for this (IE open other proposals)
The intent of this proposal is to set our pace and how nightly will be turned into a full release. Anything pertaining to the following should be considered outside of scope:
CC: @bnoordhuis