How do we handle a io.js v2.0 release candidate?

[Starefossen]

There has been some rumbling in the latest TC meetings, and very recently in nodejs/node#1436, about releasing one or more release candidates (RCs) for the next major version of io.js (v2.0). I can only assume that the RC versions will be available similarly to how the official builds are distributed.

How should we handle RC versions with regards to the io.js Docker image? Do we ignore them and wait until the final version has been landed? Or can we make them available through an 2.0-rc-x tag under the official image? If a tag on the official image is a no go, can we create a separate image for testing RCs? The latest tag will of course continue to point to latest 1.x version until v2.0 has been officially released.

I do think it is important to make RC versions available through the Docker image since the main purpose of an RC is to get as many people as possible to test them. What better way to test the new version than through Docker, right?! 🚀 😄

[Fishrock123]

I'm not really sure what you are talking about. release Candidates have only come up at https://github.com/jasnell/dev-policy in relation to node.

There will not be a 2.0.0.-rc in io.js. There will be nightlies, and 2.0.0.

[Starefossen]

From io.js TC Meeting 2015-04-15:

Discussed RC build, could use nightly or next-nightly but officially link it off the website and maybe label it differently. Rod to figure this out.

Rod to figure out how to do and publish an RC build that’s not just “nightly-xxxxxxxxxxxxxx”

From nodejs/node#1436:

@chrisdickinson: [...] Should we "fix" next sooner rather than later so that we can get an RC out earlier? Or should we approach re-cutting next differently (or not at all)?

@rvagg: [...] start working on 2.0.0 in master, then our RC builds can come out of there and we either tell people to just use the next-nightly builds and consider them RC or we can properly label a build or two "RC" in some way.

[Fishrock123]

Huh. oookay.

[pesho]

Are there other official Docker images which publish non-final releases?

The current process (sending a PR to docker-library/official-images for each release) is quite clumsy. I'm not sure it can accomodate an even faster release schedule (i.e. one that includes rc/next/canary releases).

[Starefossen]

Are there other official Docker images which publish non-final releases?

Yes, mysql:5.7.7-rc https://github.com/docker-library/official-images/blob/de76ad36fa8698fb5fe56eb3aa75dd128e2776e6/library/mysql#L11

The current process (sending a PR to docker-library/official-images for each release) is quite clumsy. I'm not sure it can accomodate an even faster release schedule (i.e. one that includes rc/next/canary releases).

Yes, it is a bit cumbersome. An automated build would be better suited to accommodate a faster phase.

[Starefossen]

@rvagg what is the current status of io.js v2.0 release candidate builds? Any thoughts on how many RCs there may be before the final version lands?

[pesho]

Yes, mysql:5.7.7-rc

Another example I forgot about is node image - it had tags for the unstable 0.11.x releases. I think it would be ok for us to do the same, assuming the 2.0rc releases will not be too frequent. The latest tag should keep pointing to the stable branch.

[Starefossen]

Yes, latest should absolutely point to the stable branch!

[rvagg]

We haven't had the V8 merge yet but it should land in the coming days, once that happens you could consider experimenting with RC / nightly builds and this work may be helpful for other major jumps in functionality, even releasing images based on next in the future.

Here's some relevant thoughts:

• https://iojs.org/download/nightly/ is probably the closest we'll get to "RC" builds, I think that we may not bother with actual RC builds but that might be reconsidered depending on how complex this process ends up being and how concerned we are about the code. So I suggest grabbing a nightly when the V8 upgrade lands and using that. I'll try and remember to highlight nightlies that should be considered RC builds in this thread.
• We still don't have a good solution for node-gyp working with non-release builds and I'm not sure if you're putting the source in to ~/.node-gyp in your images already but there are a couple of options you could consider to making node-gyp work nicely with nightlies:
  1. put the source, unpacked, by version, in ~/.node-gyp, the subdirectory will depend on the version string of io.js and note you don't actually need the full source tree, you really only need headers which would save a lot of space if you can work out the trimmed down version of the source!
  2. put the source, unpacked, in some predictable directory in the image (trimmed as per above) and set the image user's (I'm assuming you're now running as a non-root user, but /root/.npmrc would work too if you're not) .npmrc file to have nodedir=/path/to/source (alt: npm config set nodedir=/path/to/source), which is a bit of a hack but would be perfectly fine in an image where you have a single static version of io.js anyway.

Perhaps it's time to start experimenting at least? It'd be neat to be able to point people to an easy docker image they can use just to try out 2.0.0 before it lands proper.