Description
@nodejs/collaborators @nodejs/build @nodejs/addon-api
This issue describes a proposed strategy for generating and publishing regular builds based off our master branch. Discussion is invited!
1. Purpose
The purpose of these builds is to:
- Get our
masterwork out into public hands in an easily usable form - Seek feedback on the various breaking changes
- Encourage experimentation with new V8 features
- Encourage performance measurement and assessment the impact of our changes, and V8's, on user code
- Give NAN some test builds to use to ensure compatibility
- Give add-on authors a chance to prepare for breaking API changes
These builds, just like the nightlies, will be fully usable, node-gyp understands where to fetch headers from for these if it needs them and currently (afaik) NAN works fine with the current V8. They will actually be a drop-in replacement for Node and I'd expect early-adopter types to start using these as such. Ideally, many Node.js contributors / collaborators will be using these builds so we can start to eat our own dogfood in earnest.
2. Name
On "Canary": Our development process includes cherry-picking most changes from master to the stable branch and releasing those regularly, holding back only the semver-major changes. We also have a long window of time before we cut a new stable. Therefore I don't believe "Canary" is a great term for what we are releasing. It works for Chrome because of the shorter cycles and holding back more changes from their stable branch, it really is a canary in the coalmine in the sense that it gives them the ability to react quickly to breakage they didn't otherwise notice and prepare for an imminent release. In effect, our stable branches are a canary for LTS given our policy of waiting >=1 release before changes get in to LTS from stable.
A couple of other factors to balance in naming:
- Something short so that release files can include it and not end up excessively long.
- Something that indicates that this is not a proper release because the version number in the binary and the release files will have
6.0.0and we must make it clear that we are not releasing v6 (imagine the uproar when people see us doing v4, v5 and v6 in parallel, not to mention v0.10 and v0.12).
I propose Next as the name for these releases.
We would use https://nodejs.org/download/next/ as the download location for the builds (replacing next for whatever we agree upon for the name).
3. Frequency and automation
We already have nightlies coming out for v5.x and master (as v6.0.0...) already, available at https://nodejs.org/download/nightly/, these are automatic and happen each day whenever there are new commits on those branches.
I propose that we replace the master nightlies with a new release line that's automatic but happens each week (something like 1am Monday UTC). The purpose of making it weekly would be to:
- Make it practical to use full-time and keep updated; it'll be close in frequency to our stable releases
- Make it easier to receive feedback from users of these releases, i.e. it'll be simpler to triangulate their version number with the code they are using (it's likely we'll be able to do this even without looking at the repo); also there are fewer versions than with nightlies so it's more likely that other users and collaborators are using the same version and are experiencing similar issues
- Make a stable and consistent schedule that those more concerned with
mastercan work to, I'm thinking particularly of the @nodejs/v8 team here who will know when they need to get things in for them to go into a usable release
4. Version string
We should try and keep this as short as possible to make it more easily referencable (and also nginx's auto indexing is pretty bad with long names, although that's something we can attack creatively), but we do have lattitude to include additional information if it's of high value.
My best attempt at this is: vX.0.0-next.yyyymmdd, where X is the major version number and yyyymmdd is the date of the build.
So an example of one from this week would be: v6.0.0-next.20160125
Some thoughts on possibilities:
- Year-less dates because every second
mastercycle (i.e. major verison number) will overlap years, so releases from Jan will sort lower than Dec via semver, i.e.v6.0.0-next.0125(2016) <v6.0.0-next.1228(2015). Using a 2-char year is a possibility but it won't be as obvious to users what the number means just by looking at it:v6.0.0-next.160125 - Release numbers are a possibility, e.g.
v6.0.0-next.1,v6.0.0-next.2,v6.0.0-next.3, etc. There are two problems here: it either requires state be kept somewhere wrt what number we are up to (it is possible to look at the list of releases and figure it out, but this is annoying and potentially fragile), and it's harder to map what release # we are up to and what code is being used, we'd have to have some kind of look-up table to tell us what date a # maps to. - We could include V8 version as a semver component, it is an important piece of this (atm at least), it just gets a bit messy, e.g
v6.0.0-next.20160125+v8.49
Something else to consider here is that without the commit hash, like we have in nightlies, it won't be clear what code is in use without referring to Jenkins to see what it pulled in. If we don't have the hash in the version string then perhaps we should include it at process.release.commit or process.version.commit.