-
Notifications
You must be signed in to change notification settings - Fork 29.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Proposal: canary/next/master release strategy #4856
Comments
I still actually think To me, 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, |
Putting it all together: |
@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
|
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". |
@targos... good to know :-) |
I'm also fine with |
|
I like |
Is that valid semver? Why can't we go with the traditional alpha designation like |
I also like @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? |
actually, can we use |
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.
Yes, see the spec, you can have
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 @cjihrig we could include the hash in a build identifier and if we wanted we could even include both, |
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.
That's a vote in favor "alpha" as it is commonly expressed as |
Just realized there might be confusion using |
"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? |
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 |
@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:
master
work 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
master
to the stable branch and releasing those regularly, holding back only thesemver-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:
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
andmaster
(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
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: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 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
, whereX
is the major version number andyyyymmdd
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:
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
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.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
orprocess.version.commit
.The text was updated successfully, but these errors were encountered: