{"action":"created","issue":{"url":"https://api.github.com/repos/iojs/io.js/issues/438","labels_url":"https://api.github.com/repos/iojs/io.js/issues/438/labels{/name}","comments_url":"https://api.github.com/repos/iojs/io.js/issues/438/comments","events_url":"https://api.github.com/repos/iojs/io.js/issues/438/events","html_url":"https://github.com/iojs/io.js/issues/438","id":54426271,"number":438,"title":"Release proposal: v1.0.2","user":{"login":"rvagg","id":495647,"avatar_url":"https://avatars.githubusercontent.com/u/495647?v=3","gravatar_id":"","url":"https://api.github.com/users/rvagg","html_url":"https://github.com/rvagg","followers_url":"https://api.github.com/users/rvagg/followers","following_url":"https://api.github.com/users/rvagg/following{/other_user}","gists_url":"https://api.github.com/users/rvagg/gists{/gist_id}","starred_url":"https://api.github.com/users/rvagg/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/rvagg/subscriptions","organizations_url":"https://api.github.com/users/rvagg/orgs","repos_url":"https://api.github.com/users/rvagg/repos","events_url":"https://api.github.com/users/rvagg/events{/privacy}","received_events_url":"https://api.github.com/users/rvagg/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":11,"created_at":"2015-01-15T09:05:19Z","updated_at":"2015-01-15T18:46:03Z","closed_at":null,"body":"Going to try something different here to get agreement on pushing a patch release\r\n\r\n - It seems to me that we ought not be afraid to push patch releases fairly frequently, the longer the changelog the more potential for trouble so let's just ship code\r\n - getting enough people around on IRC at the same time to get an agreement on a release is tricky and we'd have to come up with rules about what collection of people could authorize one\r\n - waiting for a TC meeting could be too long where there are important things to release\r\n - waiting for a TC meeting also excludes input from other collaborators\r\n - we already have a process around issues and pull requests and seeking consensus, or at least the lack of dissension\r\n\r\nSo, how about any collaborator who thinks there should be a patch release propose it via github along with the changelog, a CI link and/or nightlies containing the changes to be released and we get sign-off here. Sign-off for a release can just be a matter of:\r\n - enough delay to allow input from around the globe (although I think in this case I think we could make 24 hours or a little less)\r\n - gather +1's from collaborators (not just TC members)\r\n - a -1 from a collaborator should lead to discussion and an attempt to find agreement\r\n - .. perhaps a failure to resolve a -1 means that TC gets to decide by majority?\r\n\r\nAny critical releases can be handled in an appropriate way--where there are security concerns these could be expedited and done fairly privately until the release is out by those who have access to cut a release.\r\n\r\nSo consider this issue my proposal for a 1.0.2 release.\r\n\r\nHere's a nightly from just now: https://iojs.org/download/nightly/v1.0.2-nightly201501158440cacb10/\r\n\r\nHere's a Jenkins run I've just started: https://jenkins-iojs.nodesource.com/job/iojs+any-pr+multi/79/\r\n\r\nHere's a changelog so far:\r\n\r\n* src: fix documentation url in help message (Shigeki Ohtsu)\r\n* win,msi: warn that older io.js needs manual uninstall (Bert Belder)\r\n* win,msi: change UpgradeCode (Bert Belder)\r\n* deps: make node-gyp work again on windows (Bert Belder)\r\n* deps: update libuv to 1.2.1 (Saúl Ibarra Corretgé)\r\n* doc: mention io.js alongside Node in Punycode docs (Mathias Bynens)\r\n* deps: update http_parser to 2.4.1 (Fedor Indutny)\r\n* doc: update cluster entry in CHANGELOG (Ben Noordhuis)\r\n* doc: fix double smalloc example (Mathias Buus)\r\n\r\nI'm mainly interested in this for the windows node-gyp fix but the upgrades to libuv and http_parser are also worthy of release.\r\n\r\nI'm also working to make it so that >1 person can make formal releases. A select few people should be able to make a release by:\r\n\r\n 1. creating a signed tag for the release in the codebase (and doing the bits that need doing in node_version.h)\r\n 1. running the iojs+release job on Jenkins\r\n 1. running a shell script on their own machine as well as the web server to promote the builds to the release directory and sign the shasums with the same GPG key used to sign the git tag\r\n\r\nIt's this last step that needs a bit of work. I'll have to give these people access to the server and set up a script that does the work on the remote to promote and locally to sign. I have these pieces in 2 parts now but they could be combined and I need to sort out permissions properly on the server so it's more secure to allow others in to this process.\r\n\r\nOf course, the more GPG keys we have signing shasums, the more we need to list somewhere for people to authenticate our builds with so I also propose we list everyone who has signed a release from io.js on the README along with the id of their GPG key so it can be easily fetched (there is already a collaborator list so ids could just go on there). We should also document how people can verify downloads."},"comment":{"url":"https://api.github.com/repos/iojs/io.js/issues/comments/70138339","html_url":"https://github.com/iojs/io.js/issues/438#issuecomment-70138339","issue_url":"https://api.github.com/repos/iojs/io.js/issues/438","id":70138339,"user":{"login":"piscisaureus","id":218257,"avatar_url":"https://avatars.githubusercontent.com/u/218257?v=3","gravatar_id":"","url":"https://api.github.com/users/piscisaureus","html_url":"https://github.com/piscisaureus","followers_url":"https://api.github.com/users/piscisaureus/followers","following_url":"https://api.github.com/users/piscisaureus/following{/other_user}","gists_url":"https://api.github.com/users/piscisaureus/gists{/gist_id}","starred_url":"https://api.github.com/users/piscisaureus/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/piscisaureus/subscriptions","organizations_url":"https://api.github.com/users/piscisaureus/orgs","repos_url":"https://api.github.com/users/piscisaureus/repos","events_url":"https://api.github.com/users/piscisaureus/events{/privacy}","received_events_url":"https://api.github.com/users/piscisaureus/received_events","type":"User","site_admin":false},"created_at":"2015-01-15T18:46:03Z","updated_at":"2015-01-15T18:46:03Z","body":"@rvagg \r\nAs far as I'm concerned we do patch releases as frequently as we can. We don't even need to have a +1 from *every* collaborator.\r\n\r\nWhen releases are infrequent there is often an incentive for collaborators to hold up the release to get \"just that one extra patch\" in. That goes away if we release frequently enough. It is however absolutely important to keep the build green at all times.\r\n\r\n+1 on v1.0.2.\r\n"}}