René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Release Cycle Proposal","articleBody":"## Context\n\nWhenever 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.\n## Release Promotion\n\nThe 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](http://blog.chromium.org/2010/07/release-early-release-often.html), [Firefox](https://blog.mozilla.org/channels/2011/07/18/every-six-weeks/), and now [Rust](http://blog.rust-lang.org/2014/12/12/1.0-Timeline.html). 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.\n\nThis 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.\n\nThe 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.\n\nI 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.\n## Cycle Duration\n\nWe 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. \n\nThis 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.\n\nSide 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.\n## Caveats\n\nIn 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.\n## Outside of scope for this (IE open other proposals)\n\nThe 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:\n- How we determine what to merge into nightly\n- When to merge into nightly (regarding things that may bump different chunks of the version number)\n- Feature flags or other opt in functionality\n- Deprecation process\n- Long term support verisons\n\nCC: @bnoordhuis \n","author":{"url":"https://github.com/wraithan","@type":"Person","name":"wraithan"},"datePublished":"2014-12-15T21:47:10.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":8},"url":"https://github.com/168/node/issues/168"}