{"action":"created","issue":{"url":"https://api.github.com/repos/nodejs/io.js/issues/1997","labels_url":"https://api.github.com/repos/nodejs/io.js/issues/1997/labels{/name}","comments_url":"https://api.github.com/repos/nodejs/io.js/issues/1997/comments","events_url":"https://api.github.com/repos/nodejs/io.js/issues/1997/events","html_url":"https://github.com/nodejs/io.js/issues/1997","id":88865127,"number":1997,"title":"Proposal: Release Process","user":{"login":"mikeal","id":579,"avatar_url":"https://avatars.githubusercontent.com/u/579?v=3","gravatar_id":"","url":"https://api.github.com/users/mikeal","html_url":"https://github.com/mikeal","followers_url":"https://api.github.com/users/mikeal/followers","following_url":"https://api.github.com/users/mikeal/following{/other_user}","gists_url":"https://api.github.com/users/mikeal/gists{/gist_id}","starred_url":"https://api.github.com/users/mikeal/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/mikeal/subscriptions","organizations_url":"https://api.github.com/users/mikeal/orgs","repos_url":"https://api.github.com/users/mikeal/repos","events_url":"https://api.github.com/users/mikeal/events{/privacy}","received_events_url":"https://api.github.com/users/mikeal/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/nodejs/io.js/labels/discuss","name":"discuss","color":"02d7e1"},{"url":"https://api.github.com/repos/nodejs/io.js/labels/meta","name":"meta","color":"fef2c0"}],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":46,"created_at":"2015-06-16T23:21:16Z","updated_at":"2015-06-17T20:41:09Z","closed_at":null,"body":"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.\r\n\r\nFirst, I should lay out the different concerns the release process needs to satisfy.\r\n\r\n* We need to take new versions of v8 in a timely manor.\r\n  * We need to do real releases (not just nightlies) that are *in use*.\r\n   * If we don't do this we fall too far behind the v8 cycle and can't collaborate effectively.\r\n   * 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.\r\n* We need to release contributions in a timely and usable manor.\r\n * The vast majority of contributions are not breaking changes but patches and feature additions.\r\n * 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.\r\n * 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.\r\n* 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.\"\r\n* 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.\r\n\r\nOne 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.\r\n\r\nHere's my proposal, laid out by branch.\r\n\r\n## master branch\r\n\r\nMaster 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.\r\n\r\n### incubation period\r\n\r\nMaster 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.\r\n\r\n## next branch\r\n\r\nMultiple 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.\r\n\r\nApproximately 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.\r\n\r\n## LTS branches\r\n\r\nWhen `next` merges in to `master` we create a new branch for that major release's LTS line (as we do today).\r\n\r\nThe STABLE channel contains that latest LTS release of the latest major version under LTS.\r\n\r\n## Website Mockup\r\n\r\n```\r\n---------------------------------------------\r\n|         |         |        |              |\r\n| STABLE  | CURRENT |  BETA  |    CANARY    |\r\n| 0.10.99 | 2.89.4  | 2.91.2 | 3.0 Alpha 14 |\r\n|         |         |        |              |\r\n---------------------------------------------\r\n```\r\n\r\n## User Expectations\r\n\r\nDevelopers 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.\r\n\r\nMost 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.\"\r\n\r\nLarger 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.\r\n\r\n## Current Versions, Branding and the Convergence.\r\n\r\nIf we adopt this release process we should scrap our current convergence plan.\r\n\r\nFeatures 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`.\r\n\r\nAll 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.\r\n\r\n* STABLE is 0.10.x\r\n* CURRENT and BETA are 2.x\r\n* CANARY is 3.x\r\n\r\nI 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."},"comment":{"url":"https://api.github.com/repos/nodejs/io.js/issues/comments/112943627","html_url":"https://github.com/nodejs/io.js/issues/1997#issuecomment-112943627","issue_url":"https://api.github.com/repos/nodejs/io.js/issues/1997","id":112943627,"user":{"login":"domenic","id":617481,"avatar_url":"https://avatars.githubusercontent.com/u/617481?v=3","gravatar_id":"","url":"https://api.github.com/users/domenic","html_url":"https://github.com/domenic","followers_url":"https://api.github.com/users/domenic/followers","following_url":"https://api.github.com/users/domenic/following{/other_user}","gists_url":"https://api.github.com/users/domenic/gists{/gist_id}","starred_url":"https://api.github.com/users/domenic/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/domenic/subscriptions","organizations_url":"https://api.github.com/users/domenic/orgs","repos_url":"https://api.github.com/users/domenic/repos","events_url":"https://api.github.com/users/domenic/events{/privacy}","received_events_url":"https://api.github.com/users/domenic/received_events","type":"User","site_admin":false},"created_at":"2015-06-17T20:41:09Z","updated_at":"2015-06-17T20:41:09Z","body":"+1.\r\n\r\nWith the caveat that, in the medium-term, I still believe we can do better with native modules and shorten the feedback loop, as discussed elsewhere. (I.e., have releases ready for testing 6-12 weeks in advance, have automated testing and perhaps even automated PRs, etc. so that in theory by the time Chrome rolls some large portion of the native module ecosystem is ready. Plus, V8's list of major upcoming breaking changes [is settling down, supposedly](https://bit.ly/v8-api-changes), but I know that's not exactly a promise that has much behind it.)"}}