{"action":"created","issue":{"url":"https://api.github.com/repos/nodejs/io.js/issues/1854","labels_url":"https://api.github.com/repos/nodejs/io.js/issues/1854/labels{/name}","comments_url":"https://api.github.com/repos/nodejs/io.js/issues/1854/comments","events_url":"https://api.github.com/repos/nodejs/io.js/issues/1854/events","html_url":"https://github.com/nodejs/io.js/issues/1854","id":83156369,"number":1854,"title":"a more deliberate release process","user":{"login":"othiym23","id":418097,"avatar_url":"https://avatars.githubusercontent.com/u/418097?v=3","gravatar_id":"","url":"https://api.github.com/users/othiym23","html_url":"https://github.com/othiym23","followers_url":"https://api.github.com/users/othiym23/followers","following_url":"https://api.github.com/users/othiym23/following{/other_user}","gists_url":"https://api.github.com/users/othiym23/gists{/gist_id}","starred_url":"https://api.github.com/users/othiym23/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/othiym23/subscriptions","organizations_url":"https://api.github.com/users/othiym23/orgs","repos_url":"https://api.github.com/users/othiym23/repos","events_url":"https://api.github.com/users/othiym23/events{/privacy}","received_events_url":"https://api.github.com/users/othiym23/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/nodejs/io.js/labels/meta","name":"meta","color":"fef2c0"}],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":19,"created_at":"2015-05-31T18:42:18Z","updated_at":"2015-06-01T08:13:32Z","closed_at":null,"body":"`<whining>`I'm going to be straight-up emotional for just a second here: this is the second Sunday in the last month where I've woken up to a brewing crisis involving io.js and npm (#1850, #1591). It is _incredibly annoying_, as well as demotivating, to have to clean up these situations on what should be one of my days off. I try very hard to be a conscientious project lead / OSS maintainer / io.js collaborator, but for human psychological and physiological reasons I need some downtime, and the weekends are that time for me. The suggestions below are offered in the spirit of making it so that I don't have to choose between being responsible to the io.js and npm user communities, and being responsible to myself. Thank you for reading this with that in mind.`</whining>`\r\n\r\nAlso, for all of the following, I frame things in terms of npm, but this is just as true of V8 and changes made to Node's own APIs.\r\n\r\nAbout a year ago this time, npm introduced a new release process that included as one of its key features the notion of publishing every new release with a [`dist-tag`](https://docs.npmjs.com/cli/dist-tag) of `next`, and only promoting it to `latest` after at least a few days (generally a week) so that interested members of the community could use / test it and identify any latent issues with the release. This was done as a reaction to what used to be an all-too-common pattern with Node.js releases, where a new release of Node.js would be followed almost immediately by another due to something messed up inside the version of npm bundled with Node, which was embarrassing and wasteful. This basically hasn't happened since npm's new process was put into place, which I think everybody agrees is a big improvement.\r\n\r\n#1850 shows that this only deals with one side of the problem, though. If there's something in a new Node release that makes it incompatible with npm, we can end up putting out versions of Node that render npm unusable, which cripples the release. There's a lot of room for improvement in how npm is tested and integrated with io.js's CI, but even with that situation substantially improved (which a number of us are working on), there's no substitute for real use of the product to give it some real-world smoke-testing.\r\n\r\nio.js has a much quicker release cadence than Node.js has had for a while, and this is one of the primary drivers of io.js's quick progress (and is great). New versions come out frequently, and when things break, a new release that fixes them is generally pretty quick to appear. However, because things like Travis pin to the latest version, and many many projects take advantage of this, official io.js releases can magnify issues into an avalanche of issue-tracker and support traffic. \r\n\r\nTherefore, I have a few suggestions I'd like to make about how io.js is released:\r\n\r\n1. when upgrading dependencies within Node, they should be included in at least 1 (preferably more) nightly release before an official release is cut (I don't know how widely-used the nightlies are, but this is better than nothing)\r\n2. to get potential releases in front of more people, it would be great to have some notion of release candidates for \"larger\" releases (semver-major definitely, semver-minor probably, semver-patch it would be nice but also probably a gratuitous amount of work _[ETA: finished incomplete thought]_)\r\n3. io.js releases should only happen during the week. I completely understand that for many io.js contributors, the weekend is the only time they have available for OSS / io.js-specific work, which is why I haven't raised this point before. At the same time, many of us are already spending pretty full weeks working on things related to Node – dealing with this is our job, and as such we just need some time off.\r\n\r\nNote that these suggestions are orthogonal to adding more / better tests of dependencies, better integration of the tests we do have into CI, acceptance tests, and other prophylaxes intended to improve release quality. All of those things would be great, as would some kind of defined QA process for the project. I still think, however, that Node and npm are both complex and widely-used enough that there's no real substitute for actual, hands-on use to help ensure quality."},"comment":{"url":"https://api.github.com/repos/nodejs/io.js/issues/comments/107355377","html_url":"https://github.com/nodejs/io.js/issues/1854#issuecomment-107355377","issue_url":"https://api.github.com/repos/nodejs/io.js/issues/1854","id":107355377,"user":{"login":"targos","id":2352663,"avatar_url":"https://avatars.githubusercontent.com/u/2352663?v=3","gravatar_id":"","url":"https://api.github.com/users/targos","html_url":"https://github.com/targos","followers_url":"https://api.github.com/users/targos/followers","following_url":"https://api.github.com/users/targos/following{/other_user}","gists_url":"https://api.github.com/users/targos/gists{/gist_id}","starred_url":"https://api.github.com/users/targos/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/targos/subscriptions","organizations_url":"https://api.github.com/users/targos/orgs","repos_url":"https://api.github.com/users/targos/repos","events_url":"https://api.github.com/users/targos/events{/privacy}","received_events_url":"https://api.github.com/users/targos/received_events","type":"User","site_admin":false},"created_at":"2015-06-01T08:13:32Z","updated_at":"2015-06-01T08:13:32Z","body":"Maybe to avoid this kind of issues in the future, `Symbol`s should be used systematically for internal properties when new features are added.\r\nThat way when people in userland need to access something that was not initially in the API they would come here and ask for it instead of hacking with _values without telling anyone."}}