Release proposal: v1.0.2

[rvagg]

Going to try something different here to get agreement on pushing a patch release

• 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
• 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
• waiting for a TC meeting could be too long where there are important things to release
• waiting for a TC meeting also excludes input from other collaborators
• we already have a process around issues and pull requests and seeking consensus, or at least the lack of dissension

So, 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:

• 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)
• gather +1's from collaborators (not just TC members)
• a -1 from a collaborator should lead to discussion and an attempt to find agreement
• .. perhaps a failure to resolve a -1 means that TC gets to decide by majority?

Any 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.

So consider this issue my proposal for a 1.0.2 release.

Here's a nightly from just now: https://iojs.org/download/nightly/v1.0.2-nightly201501158440cacb10/

Here's a Jenkins run I've just started: https://jenkins-iojs.nodesource.com/job/iojs+any-pr+multi/79/

Here's a changelog so far:

• src: fix documentation url in help message (Shigeki Ohtsu)
• win,msi: warn that older io.js needs manual uninstall (Bert Belder)
• win,msi: change UpgradeCode (Bert Belder)
• deps: make node-gyp work again on windows (Bert Belder)
• deps: update libuv to 1.2.1 (Saúl Ibarra Corretgé)
• doc: mention io.js alongside Node in Punycode docs (Mathias Bynens)
• deps: update http_parser to 2.4.1 (Fedor Indutny)
• doc: update cluster entry in CHANGELOG (Ben Noordhuis)
• doc: fix double smalloc example (Mathias Buus)

I'm mainly interested in this for the windows node-gyp fix but the upgrades to libuv and http_parser are also worthy of release.

I'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:

1. creating a signed tag for the release in the codebase (and doing the bits that need doing in node_version.h)
2. running the iojs+release job on Jenkins
3. 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

It'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.

Of 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.

[phpnode]

This is an excellent idea!

[daxingplay]

I agree

[idx3d]

I'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

Those guys should be from TC?

[rvagg]

@Leukhin not necessarily but they certainly need to be trusted by the TC because we're giving a lot of power and we need to protect the integrity of the release process and the builds themselves.

[Cangit]

Being slow to ship code is one of the reason's this project was born. I would love to see aggressive release schedules. +1 👍

[lijunle]

Good to see the community version of node. It is time for me to uninstall nodejs and install iojs. 👍

[ilanbiala]

I think patches should be like 1/week and a half, minors should be about 1/month and a half, and majors should be behind Chrome's release cycle by 1, so that we hopefully will never get any nasty bug that wasn't caught.

EDIT: This also makes sure that developers aren't upgrading their servers every 1.5 months, which would be way too often for a company to do.

[bnoordhuis]

@rvagg +1 in general but can you clarify why the shell script has to run locally? Does it download the release artifacts, sign them, and upload them again?

[chrisdickinson]

This SGTM in general. A few questions:

1. How doggedly are we following semver? For example, I'd like to move the auto-loading of builtin modules out of the repl module and into a private "iojs repl" module. that would remove a feature that was there, that would constitute a major version release, per semver. Would merging that mean that we were working on a v2.x branch? If so, that might screw up other PRs in flight. Would it be better to always work off of master, and save v1.x branches for LTS releases? This part might be for discussion in another issue. We should probably document how we decide which patches are major, minor, or patch beyond what semver specifies, so that collaborators have a place to look to when proposing a non-breaking change.
   1. (One route here might be "if it adds a new section to the docs, it's a minor release, if not, it's a patch release" for non-breaking changes).
   2. If we stick to semver, I'm okay with collaborators proposing both minor and patch version releases.
2. How does this play into LTS releases in the future?
   1. "minor" commits don't get backported, but "patch" commits do?
   2. Do we designate "owners" / "release managers" for LTS releases? Would they have say in what patches get backported from future releases?
3. Are we going to designate different release managers for different releases? Should that be a relatively permanent role, with emphasis on making sure a release is good to go (vs. necessarily being the one to "press the button")?

We probably don't need to address all of the above now, but I'd like to get folks discussing it in a textual form.

I'm totally on board with what you've proposed, and I'd like someone to start issues/prs for things like LTS, how we follow semver, and release management.

[yosuke-furukawa]

+1 !!
currently, i am trying to test benchmark. http is faster than node.js latest version.

#345 (comment)

[piscisaureus]

@rvagg
As 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.

When 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.

+1 on v1.0.2.

[rmg]

+1 on releasing v1.0.2 while the change list is short. Especially because of the node-gyp upgrade. It would suck if something even a little controversial lands and delays such small but important fixes.

[rvagg]

@bnoordhuis: re script, I'm thinking of something like ssh dist@iojs.org cat release.sh | bash - which will then do another ssh back in to the server to promote the builds but it'll also scp SHASUMS256.txt for local gpg signing and then scp SHASUMS256.txt, SHASUMS256.txt.asc and SHASUMS256.txt.gpg back to the release. So the only local stuff is that gpg stuff which is purely about using the gpg key of the person doing the release. release.sh can be kept on the server (hence the initial ssh) mainly to have a single place to maintain it and it's only fetchable by people with access to to the dist account on the server then. The signing of binaries and installers for OSX and Windows will be embedded into the release build servers and I'll just be keeping them isolated and protected and they won't need to be touched.

@chrisdickinson I limited this issue to just patch releases but those are all valid questions for discussion, particularly relevant here is ensuring that a patch release really is a patch release and shouldn't have been a minor. We should sort out some kind of process or technical mechanism to help keep that in track because thar be dragons.

Current changelog looks like this:

• 9b81c3e - doc: fix author attribution (Tom Hughes)
• fd30eb2 - src: fix jslint errors (Yosuke Furukawa)
• 946eabd - tools: update closure linter to 2.3.17 (Yosuke Furukawa)
• 9e62ae4 - _debug_agent: use readableObjectMode option (Vladimir Kurchatkin)
• eec4c81 - doc: fix formatting in LICENSE for RTF generation (Rod Vagg)
• e789103 - doc: fix 404s for syntax highlighting js (Phil Hughes)
• ca039b4 - src: define AI_V4MAPPED for OpenBSD (Aaron Bieber)
• 753fcaa - doc: extend example of http.request by end event (Michal Tehnik)
• 8440cac - src: fix documentation url in help message (Shigeki Ohtsu)
• 24def66 - win,msi: warn that older io.js needs manual uninstall (Bert Belder)
• 59d9361 - win,msi: change UpgradeCode (Bert Belder)
• 5de334c - deps: make node-gyp work again on windows (Bert Belder)
• 07bd05b - deps: update libuv to 1.2.1 (Saúl Ibarra Corretgé)
• e177377 - doc: mention io.js alongside Node in Punycode docs (Mathias Bynens)
• 598efcb - deps: update http_parser to 2.4.1 (Fedor Indutny)
• 3dd7ebb - doc: update cluster entry in CHANGELOG (Ben Noordhuis)
• 0c5de1f - doc: fix double smalloc example (Mathias Buus)

I'm not sure if we should restrict patch releases to just the commits initially proposed or let the list grow until the release is made, but I'm going to go with the latter in this case unless I'm told otherwise.

[rvagg]

• c80a944 - doc: Add http keepalive behavior to CHANGELOG.md (Isaac Z. Schlueter)

I'd like to also get in #462, that's just a doc update too

Tests are being run @ https://jenkins-iojs.nodesource.com/job/iojs+any-pr+multi/80/ for c80a944

[rvagg]

Nightly: https://jenkins-iojs.nodesource.com/job/iojs+release+nightly/58/ it will be 20150116265cb76517