Proposal: canary/next/master release strategy

[rvagg]

@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 master work 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.0 and 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 master can 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 master cycle (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.

[Fishrock123]

I still actually think dev may me more indicative of what is going on and the relative level of stability.

To me, next sounds like it would be a week ahead of regular releases, like npm's next is.

We originally discussed releasing (almost only) after a new V8 releases, wouldn't that kinda still be more usable? I think weekly (potentially breaking) releases might be quite hard to keep up with for people who are interested. We could kick the build off manually if anything security comes up..

I think yeared dates are more broadly understandable, even if perhaps unnecessary.

The V8 version is probably useful given my second statement, +metadata isn't version-checked by semver parsers, so it's literally only an indicator on the downloads site. A good one, I think.

[jasnell]

• +1 to dev as opposed to next
• If we are releasing at the start of each week, year + week number might be easier as a rolling tracking number, e.g. 2016w05, 2016w06, etc. It gives us the advantage of release numbers but without the state tracking or lookup table
• Including the v8 version short term is likely a good idea but we'll need to revisit that later if we decided to take on chakra officially.

Putting it all together: v6.0.0-dev.2016w05+v8.49

[Fishrock123]

@jasnell I'm pretty sure the SemVer spec says you can't put non-numeric characters into anything except the metadata. At very least, I doubt node-semver would like that much.

[jasnell]

Argh! Foiled again! OK, that minus the w :)
On Jan 25, 2016 8:27 AM, "Jeremiah Senkpiel" notifications@github.com
wrote:

@jasnell https://github.com/jasnell I'm pretty sure the SemVer spec
says you can't put non-numeric characters into anything except the
metadata. At very least, I doubt node-semver would like that much.

—
Reply to this email directly or view it on GitHub
#4856 (comment).

[targos]

The semver spec allows alphanumerical characters: http://semver.org/#spec-item-9

Just posting the output of node-semver as reference:

> semver.parse('v6.0.0-dev.2016w05+v8.49')
SemVer {
  loose: undefined,
  raw: 'v6.0.0-dev.2016w05+v8.49',
  major: 6,
  minor: 0,
  patch: 0,
  prerelease: [ 'dev', '2016w05' ],
  build: [ 'v8', '49' ],
  version: '6.0.0-dev.2016w05' }

[domenic]

I like "next" a lot more than "dev". Another possibility might be "edge".

[jasnell]

@targos... good to know :-)

[Fishrock123]

I'm also fine with edge.

[indutny]

edge looks good to me as well, it has some positive context in it.

[evanlucas]

I like edge

[mikeal]

Is that valid semver?

Why can't we go with the traditional alpha designation like 6.0.0-alpha.1?

[cjihrig]

I also like edge, and would prefer to include years if we use dates.

@rvagg you touched on the commit hash not being part of the version? Is there a reason not to use it instead of the v8 version?

[mikeal]

actually, can we use unstable? that would put it in-line with what we want the channel to be named, and i significantly clearer in terms of expectations.

[rvagg]

can we use unstable? that would put it in-line with what we want the channel to be named

I'm not sure I'm aware of a discussion that says that's what we want it to be named, do you have a link for this? See OP because basically I'm asking for this discussion to happen now. Also see my point above about preferring a short a name as possible.

Is that valid semver?

Yes, see the spec, you can have .'s in your pre-release as well as build identifiers appended with + that don't impact sorting.

Why can't we go with the traditional alpha designation like 6.0.0-alpha.1?

See OP re numbering, I'm not saying no, just that it may not be the best for various reasons, happy to discuss those reasons though.

Re edge, I can roll with that as long as we're comfortable overloading a term that Microsoft have invested heavily in using for a specific purpose.

@cjihrig we could include the hash in a build identifier and if we wanted we could even include both, v6.0.0-next.20160125+v8.49+f83ee12 is valid semver. The problem with including any of this build information in the version string is adding to the length of it. The longer it is the messier the path that someone has to take to download it and the scarier it looks so (IMO) the more unlikely it is that people will actually use these. The simplicity of something like v6.0.0-edge.11 is much more palatable. v6.0.0-edge.20160125 is grokkable and is really simple for everyone to understand what the code is based on, but the length might make it a bit more intimidating.

[mikeal]

I'm not sure I'm aware of a discussion that says that's what we want it to be named, do you have a link for this? See OP because basically I'm asking for this discussion to happen now.

So, the conversation I had with people from marketing and also a few random people we pulled into a conversation about this at Node.js Interactive the preference was to name the channels: Stable, Current, Unstable. We should probably kick something more formal off about this though.

My preference would be for the CTC to request a recommendation from the marketing committee on this. It'll go a lot smoother now that a rep from LTS and Inclusivity are both observers in the marketing committee.

Also see my point above about preferring a short a name as possible.

That's a vote in favor "alpha" as it is commonly expressed as -a.

[mikeal]

Just realized there might be confusion using edge in light of the Chakra efforts since Chakra is the VM in the Microsoft's Edge browser.

[bnoordhuis]

Stable, Current, Unstable

"Is Current not stable?" <- I'll bet good money this question will come up again and again and again.

[Fishrock123]

"Is Current not stable?" <- I'll bet good money this question will come up again and again and again.

If we make the switch and this happens: I told you all.

[thefourtheye]

+1 dev

Will we have proper changelogs for all the builds?

[rvagg]

Will we have proper changelogs for all the builds?

They will be automated, but we could automate a changelog, that'd probably be nice to have. We just need a place to put it, perhaps in the download directory as a separate file.

[mhdawson]

I prefer dev as well

[rvagg]

V8 4.9 landing is probably a good time to get this going. I'll try and get it sorted over the weekend or early next week and we can start promoting!

[dlmanning]

Stable vs. Current is super confusing. Frankly, calling one of the channels stable is a bit like calling it "Node.js: The No-Asbestos Edition!"

How about the channel 'latest'?

[evanlucas]

Does this need to stay open? We do currently have nightlies. Also, nodejs/build#626