Skip to content

Proposal: canary/next/master release strategy #4856

Closed
Closed
Proposal: canary/next/master release strategy#4856
Labels
buildIssues and PRs related to Node.js builds or CI infrastructure.discussIssues opened for discussion and feedback.metaIssues and PRs related to the general management of the project.

Description

@rvagg
rvagg
opened on Jan 25, 2016

@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.

Activity

  1. r-52
    added
    discussIssues opened for discussion and feedback.
    buildIssues and PRs related to Node.js builds or CI infrastructure.
    metaIssues and PRs related to the general management of the project.
    on Jan 25, 2016

  2. Fishrock123 commented on Jan 25, 2016

    @Fishrock123
    Fishrock123
    on Jan 25, 2016
    Contributor

    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.

  3. jasnell commented on Jan 25, 2016

    @jasnell
    jasnell
    on Jan 25, 2016
    Member
    • +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

  4. Fishrock123 commented on Jan 25, 2016

    @Fishrock123
    Fishrock123
    on Jan 25, 2016
    Contributor

    @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.

  5. jasnell commented on Jan 25, 2016

    @jasnell
    jasnell
    on Jan 25, 2016
    Member

    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).

  6. targos commented on Jan 25, 2016

    @targos
    targos
    on Jan 25, 2016
    Member

    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' }

  7. domenic commented on Jan 25, 2016

    @domenic
    domenic
    on Jan 25, 2016
    Contributor

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

  8. jasnell commented on Jan 25, 2016

    @jasnell
    jasnell
    on Jan 25, 2016
    Member

    @targos... good to know :-)

  9. Fishrock123 commented on Jan 25, 2016

    @Fishrock123
    Fishrock123
    on Jan 25, 2016
    Contributor

    I'm also fine with edge.

  10. indutny commented on Jan 25, 2016

    @indutny
    indutny
    on Jan 25, 2016
    Member

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

  11. evanlucas commented on Jan 25, 2016

    @evanlucas
    evanlucas
    on Jan 25, 2016
    Contributor

    I like edge

  12. mikeal commented on Jan 25, 2016

    @mikeal
    mikeal
    on Jan 25, 2016
    Contributor

    Is that valid semver?

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

  13. cjihrig commented on Jan 25, 2016

    @cjihrig
    cjihrig
    on Jan 25, 2016
    Contributor

    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?

  14. mikeal commented on Jan 25, 2016

    @mikeal
    mikeal
    on Jan 25, 2016
    Contributor

    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.

  15. rvagg commented on Jan 25, 2016

    @rvagg
    rvagg
    on Jan 25, 2016
    MemberAuthor

    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.

  16. mikeal commented on Jan 25, 2016

    @mikeal
    mikeal
    on Jan 25, 2016
    Contributor

    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.

  17. mikeal commented on Jan 25, 2016

    @mikeal
    mikeal
    on Jan 25, 2016
    Contributor

    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.

  18. bnoordhuis commented on Jan 26, 2016

    @bnoordhuis
    bnoordhuis
    on Jan 26, 2016
    Member

    Stable, Current, Unstable

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

  19. Fishrock123 commented on Jan 26, 2016

    @Fishrock123
    Fishrock123
    on Jan 26, 2016
    Contributor

    "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.

  20. thefourtheye commented on Jan 27, 2016

    @thefourtheye
    thefourtheye
    on Jan 27, 2016
    Contributor

    +1 dev

    Will we have proper changelogs for all the builds?

  21. rvagg commented on Jan 28, 2016

    @rvagg
    rvagg
    on Jan 28, 2016
    MemberAuthor

    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.

  22. mhdawson commented on Feb 16, 2016

    @mhdawson
    mhdawson
    on Feb 16, 2016
    Member

    I prefer dev as well

  23. rvagg commented on Mar 3, 2016

    @rvagg
    rvagg
    on Mar 3, 2016
    MemberAuthor

    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!

  24. dlmanning commented on Mar 3, 2016

    @dlmanning
    dlmanning
    on Mar 3, 2016

    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'?

  25. evanlucas commented on Feb 16, 2017

    @evanlucas
    evanlucas
    on Feb 16, 2017
    Contributor

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

  26. addaleax commented on May 27, 2017

    @addaleax
    addaleax
    on May 27, 2017
    Member

    Does this need to stay open?

    I don’t think so.

  27. addaleax
    closed this as completedon May 27, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    buildIssues and PRs related to Node.js builds or CI infrastructure.discussIssues opened for discussion and feedback.metaIssues and PRs related to the general management of the project.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions