Repository navigation
Proposal: canary/next/master release strategy #4856
Description
Activity
I still actually think
devmay me more indicative of what is going on and the relative level of stability.To me,
nextsounds like it would be a week ahead of regular releases, like npm'snextis.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,
+metadataisn't version-checked by semver parsers, so it's literally only an indicator on the downloads site. A good one, I think.- +1 to
devas opposed tonext - 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- +1 to
@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.
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).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' }
I like "next" a lot more than "dev". Another possibility might be "edge".
I'm also fine with
edge.edgelooks good to me as well, it has some positive context in it.I like
edgeIs that valid semver?
Why can't we go with the traditional alpha designation like
6.0.0-alpha.1?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.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+f83ee12is 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 likev6.0.0-edge.11is much more palatable.v6.0.0-edge.20160125is 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.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.Just realized there might be confusion using
edgein light of the Chakra efforts since Chakra is the VM in the Microsoft's Edge browser.Stable, Current, Unstable
"Is Current not stable?" <- I'll bet good money this question will come up again and again and again.
"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.
+1 dev
Will we have proper changelogs for all the builds?
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.
I prefer dev as well
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!
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'?
Does this need to stay open? We do currently have nightlies. Also, nodejs/build#626
Does this need to stay open?
I don’t think so.
@nodejs/collaborators @nodejs/build @nodejs/addon-api
This issue describes a proposed strategy for generating and publishing regular builds based off our
masterbranch. Discussion is invited!1. Purpose
The purpose of these builds is to:
masterwork out into public hands in an easily usable formThese 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
masterto the stable branch and releasing those regularly, holding back only thesemver-majorchanges. 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:
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
nextfor whatever we agree upon for the name).3. Frequency and automation
We already have nightlies coming out for
v5.xandmaster(asv6.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
masternightlies 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: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 release4. 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, whereXis the major version number andyyyymmddis the date of the build.So an example of one from this week would be:
v6.0.0-next.20160125Some thoughts on possibilities:
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.160125v6.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.v6.0.0-next.20160125+v8.49Something 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.commitorprocess.version.commit.