Repository navigation
Release proposal: v1.0.2 #438
Description
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:
- creating a signed tag for the release in the codebase (and doing the bits that need doing in node_version.h)
- running the iojs+release job on Jenkins
- 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.
Activity
phpnode commentedon Jan 15, 2015
This is an excellent idea!
daxingplay commentedon Jan 15, 2015
I agree
idx3d commentedon Jan 15, 2015
Those guys should be from TC?
rvagg commentedon Jan 15, 2015
@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 commentedon Jan 15, 2015
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 commentedon Jan 15, 2015
Good to see the community version of node. It is time for me to uninstall nodejs and install iojs. 👍
ilanbiala commentedon Jan 15, 2015
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 commentedon Jan 15, 2015
@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 commentedon Jan 15, 2015
This SGTM in general. A few questions:
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 aThis 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.v2.xbranch? 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?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 commentedon Jan 15, 2015
+1 !!
currently, i am trying to test benchmark. http is faster than node.js latest version.
#345 (comment)
piscisaureus commentedon Jan 15, 2015
@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 commentedon Jan 15, 2015
+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 commentedon Jan 16, 2015
@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.shcan be kept on the server (hence the initialssh) mainly to have a single place to maintain it and it's only fetchable by people with access to to thedistaccount 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:
readableObjectModeoption (Vladimir Kurchatkin)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 commentedon Jan 16, 2015
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 commentedon Jan 16, 2015
Nightly: https://jenkins-iojs.nodesource.com/job/iojs+release+nightly/58/ it will be
20150116265cb76517rvagg commentedon Jan 16, 2015
released @ https://iojs.org/dist/v1.0.2/
changelog has the commits and also a more digestible section with notable changes
Release took a while because I was messing around with the installers so did a few rebuilds. OS X and Windows installers are now being signed as part of the build process (for nightlies too!); although on Windows 8.x we need to build trust to get past SmartScreen without a warning. I don't know how long that will take but hopefully with lots of downloads it'll come sooner rather than later.
I'm also seeing this on Windows Chrome:
I've logged in to Google Webmaster Tools for our site and don't see any malware warnings. I'm hoping this is just because the site is new and that it'll start being cool with our downloads soon. I'll monitor Webmaster Tools to see if anything comes up.
rvagg commentedon Jan 19, 2015
By my testing we seem to be beyond both Chrome's .msi download warning and SmartScreen, so download -> run installer is working without any warnings for me now. Can someone else confirm this on their Windows 8.1 please?
kenany commentedon Jan 19, 2015
@rvagg No SmartScreen warning on my machine :)