Node: Proposal: Release Process

[mikeal]

Several discussions and threads have made it clear that the existing release policy is not working for a lot of users and developers. At NodeConf Adventure we had a few sessions about this and, with more users than node core developers, we came to very different conclusions than we have in prior threads and TSC meetings.

First, I should lay out the different concerns the release process needs to satisfy.

• We need to take new versions of v8 in a timely manor.
  
  
  
  • We need to do real releases (not just nightlies) that are _in use_.
  
  
  • If we don't do this we fall too far behind the v8 cycle and can't collaborate effectively.
  
  
  • There's a growing contingent of users that want to adopt new language features and would like to have access to them on roughly the same schedule Chrome is releasing them.
  
  
• We need to release contributions in a timely and usable manor.
  
  
  
  • The vast majority of contributions are not breaking changes but patches and feature additions.
  
  
  • The current schedule for breaking native addons means that most contributions are being released in a version that is not usable by the vast majority of users because the timeline for native addons being updated is longer than our major release cycle.
  
  
  • We need an incubation phase for these releases to validate there are no breaking changes. The number of breaks we've had in CURRENT leads people to avoid it and actively advocate that people don't run it.
  
  
• We need a release line that is _extra_ stable and a way to signal when a breaking release in this line is ready to be adopted. Actual quote: "I won't run a release line that hasn't been in wide use for a year."
• We need LTS releases and an LTS guarantee that is achievable. On a 5 year support timeline this means that we have to support (major releases per year * 5). If we do a six week major cycle that means 43 support lines -- that is not achievable.

One thing that should be clear by now is that users who wish to "adopt new JS language features" cannot rely on native addons. Those two priorities are simply incompatible at this time. We have good ideas about how to improve this in the future but we aren't there yet and v8 is going to break native addons each release for the foreseeable future.

Here's my proposal, laid out by branch.

master branch

Master should release on the same cycle and frequency we have now. Releases should appear in the BETA channel. If a critical bug or regression is found the PR fixing it should be tagged and merged.

incubation period

Master releases appear in the beta channel. If a critical bug is not tagged and merged within the incubation period the last release _older_ than the incubation period is moved to the CURRENT channel.

next branch

Multiple updates to v8 should appear in the next branch. Relatively frequent releases should appear in the CANARY channel with increasing alpha version numbers (i.e. 3.0.0-alpha19). Any breaking changes being considered should also appear in the next branch.

Approximately once a year the next branch should be merged in to master and all the appropriate version numbers kicked over. This is at the discretion of the TSC but should likely happen when there is a good level of confidence in the stability of v8.

LTS branches

When next merges in to master we create a new branch for that major release's LTS line (as we do today).

The STABLE channel contains that latest LTS release of the latest major version under LTS.

Website Mockup

|         |         |        |              |
| STABLE  | CURRENT |  BETA  |    CANARY    |
| 0.10.99 | 2.89.4  | 2.91.2 | 3.0 Alpha 14 |
|         |         |        |              |
---------------------------------------------

User Expectations

Developers who want to adopt new features will follow the CANARY channel. We can do evangelism around major events in the alpha cycle based on features that land from v8 or other major changes that might land. We should expect this section of the community to slowly move away from any dependence on native modules.

Most people involved in regular core development will sit on the BETA channel. Large institutions and popular open source projects should point their test automation at the BETA channel and encourage their users to adopt the CURRENT channel. The CURRENT major lives for about a year, which is about how long it takes for the entire native ecosystem to "catch up."

Larger production users should track STABLE. When upgrading to a new major release of STABLE the expectation is that all modules will work and have ample testing over the year of being in the CURRENT channel.

Current Versions, Branding and the Convergence.

If we adopt this release process we should scrap our current convergence plan.

Features from 0.12 should converge against io.js master. master should remain at 2.x. No breaking changes can be converged in master and should instead be done on next.

All release lines should rename to "node.js" as soon as possible and development should move to nodejs/node as soon as convergence on master is complete.

• STABLE is 0.10.x
• CURRENT and BETA are 2.x
• CANARY is 3.x

I don't know what this means for LTS of node.js 0.12 and io.js 1.x. Maybe we do it because it sends the right message but I don't think that either of these release lines should land in STABLE and we should skip over them because neither will end up going through a year in the CURRENT channel which I believe should be a requirement for this channel.

[ahmadnassri]

I'm not certain whether LTS should or shouldn't be part of the release process considerations? that is to say, there doesn't seem to be any reasoning to limit a "release process" design with identifying LTS candidates.

you could in theory identify _any_ major release as candidate for LTS, regardless of numbering or timing, that could be determined in a separate policy / process.

I can also see there's a working group discussing LTS already, so some more clarity hopefully could surface from that side.

[mikeal]

you could in theory identify any major release as candidate for LTS, regardless of numbering or timing, that could be determined in a separate policy / process.

This is what I had thought we could do a few months back but, unfortunately, it isn't quite practical. Users look for an LTS guarantee in _anything you ask them to adopt_ and we are certainly asking people to adopt CURRENT. If you do releases that you ask people to adopt and then drop support shortly after you don't end up accomplishing what LTS is designed to do: create a feeling of safety around adoption of the platform.

[chrisdickinson]

My initial reaction: I'm broadly in favor of this. We might consider changing the names of STABLE vs. CURRENT since they have the potential to direct audiences to the wrong place (namely, we want enterprise customers to choose "STABLE", we want users to choose "CURRENT.") That's a naming quibble, though.

I'm going to stew on this a bit more (especially the convergence bits), but for now, great work!

[mikeal]

@chrisdickinson I sort of stole the naming convention from FreeBSD for CURRENT and STABLE. It seems to work for them but our community is quite different so we may need to use something else.

Also, keep in mind that module authors also need a timeline for dropping support of old releases in their current development so we need something that conveys an expectation to module authors that they should still be actively supporting and testing against whatever we end up calling the STABLE channel.

[mscdex]

I also think that having both "Current" and "Stable" labels as separate things can be confusing, since it's possible to have a "current" stable version and an old stable version (e.g. v0.10.38 vs v0.10.0 or even v0.8.xx). I'm not sure what name(s) would be better though.

[chrisdickinson]

@mikeal I was (a bit cheekily, perhaps) considering calling the "STABLE" channel the "ENTERPRISE" channel. Plus, this lets us start building up a space-/sf-themed set of channels (io.js, enterprise.js, etc, etc. – just need ones for "beta" and "current") :alien:

[mikeal]

considering calling the "STABLE" channel the "ENTERPRISE"

I'm not opposed to this.

set of channels (io.js, enterprise.js, etc)

Perhaps some time in the future we can call one io.js but, at the moment, calling one of them io.js is deeply confusing :)

[ahmadnassri]

you could in theory identify any major release as candidate for LTS, regardless of numbering or timing, that could be determined in a separate policy / process.

This is what I had thought we could do a few months back but, unfortunately, it isn't quite practical. Users look for an LTS guarantee in anything you ask them to adopt and we are certainly asking people to adopt CURRENT. If you do releases that you ask people to adopt and then drop support shortly after you don't end up accomplishing what LTS is designed to do: create a feeling of safety around adoption of the platform.

I don't disagree with that statement, I guess all I'm saying is: you can create a _separate policy_ for tagging a major release as LTS, regardless of what process you use to _issue_ releases.

e.g. the LTS policy can be as simple as: "Every second major release is an LTS release", so: (major releases per year / 2).

or perhaps tie LTS with yearly quarters: 4 LTS releases per year * 5 years = 20.

[mscdex]

Does anyone have any opinions on having an LTS release schedule like that of Ubuntu's (currently an LTS release every 2 years)?

[Fishrock123]

We need LTS releases and an LTS guarantee that is achievable. On a 5 year support timeline this means that we have to support (major releases per year * 5). If we do a six week major cycle that means 43 support lines -- that is not achievable.

I think the current LTS proposals are widely misunderstood. To be fair, they are also clumsy and confusing.

The previous idea would be to widely message that only some lines will be tagged for LTS.

[mikeal]

I think the current LTS proposals are widely misunderstood. To be fair, they are also clumsy and confusing.

I think this is mostly because we have been writing them in isolation from the actual release process, which we keep changing and then expecting the LTS folks to catch up.

At various points we've externalized LTS needs by saying "the LTS WG will handle that" so we don't have to consider them in the regular release process and effectively treated the LTS WG like a dumping ground for stability concerns. Stability concerns must be a part of the regular process and the LTS WG can find the best way to coordinate the effort required to do STABLE and LTS releases once the regular process, which appreciates the time and effort required to maintain a major release line, shifts the major release cycle.

[subfuzion]

I think we should avoid conflating STABLE with LTS. If we consider the Ubuntu community's definition of LTS, it is enterprise focused and not a feature-based / cutting edge release.

Using @mikeal's website mockup, it would look like this.

|         |         |        |              |
|   LTS   | CURRENT |  BETA  |    CANARY    |
| 0.10.99 | 2.89.4  | 2.91.2 | 3.0 Alpha 14 |
|         |         |        |              |
 -------------------------------------------

I agree with @mikeal that CURRENT needs to be stable. There is no point in having current releases perceived as beta releases that organizations are afraid to adopt. I like the idea of an incubation period for releases before promoting them to the next channel.

I disagree with the need to indicated a stable line that has been in wide use for a year. LTS provides a strong stability guarantee for those who need it. Just because a release line is a year old doesn't mean it conveys any guarantee about how widely adopted and therefore vetted it was, particularly given the rapid rate of io.js releases.

An organization that wants to hold off on adopting current releases for a period of time as a matter of policy can certainly do so, but labeling an older release as stable is potentially misleading. Especially with io.js' adoption of semantic versioning, the decision whether to adopt current, remain a minor (or major) version behind, or stick with LTS should be enough for an organization.

[rvagg]

(commenting without having read the bulk of the comments yet, sorry)

Can we please remove discussion of LTS from this thread, there is almost zero overlap between the proposal(s) here for LTS and the work that's been happening in the LTS WG (on GitHub exclusively so far). This is a complex topic and requires significant commitment from certain parties that have a stronger interest in LTS than most users (as nice as it sounds to have "stability", it's not the new hotness that everyone really wants to work on, LTS work is going to be a hard, borning, tedious slog that will likely be supported primarily by corporate players with a commercial interest in this area).

So rather than allowing this discussion get into fantasy-land and therefore go nowhere can we please, please, please remove LTS from the scope and focus on other aspects of "release" instead. If you are really interested in LTS (and can realistically contribute) then pipe up in the LTS WG--as much as everyone wants to talk about it, it's been difficult to get people who will do the hard work together thus far but we'll be trying again in the coming weeks.

[subfuzion]

@rvagg, Confining LTS discussion to the LTS WG makes sense (and I completely agree with LTS being tedious -- and likely supported primarily by commercially interested, corporate players and therefore needing separate consideration).

With that being the case, I also understand the need to indicate a "stable" channel as initially presented in @mikeal's mockup. Although I still chafe at the word, there's no doubt in my mind that 0.10.* represents a pretty stable version of Node at this point. I'm not sure at which point I began to think of it as stable, but I suppose it was at some time after it had been been out for a while and gone through a number of updates. So I guess that brings me right back to the original then:

|         |         |        |              |
| STABLE  | CURRENT |  BETA  |    CANARY    |
| 0.10.99 | 2.89.4  | 2.91.2 | 3.0 Alpha 14 |
|         |         |        |              |
 -------------------------------------------

I guess what I hate about "stable" is that it will be used by so many people as a reason for not using current. Maybe we could call it VENERABLE ;)

[mikeal]

Some notes from a recent conversation with @rvagg on IRC.

• While we figure out this whole canary/beta/current thing we should stay away from discussing the LTS process. For the time being 0.10.x is the blessed LTS and the process for maintaining and releasing it can go on while we figure this out.
• Current, next is a bit stale so if we're talking about persisting it for a while we'll need to come up with a good way to keep it up to date with what lands in master
  
  
  
  • Possibly automate a rebase.
  
  
  • Possibly do time based releases to ensure we don't wait too long between.
  
  

[subfuzion]

@mikeal, when you say:

• We need to take new versions of v8 in a timely manor.
  
  
  
  • We need to do real releases (not just nightlies) that are in use.
  
  

what do you mean by "we need to do real releases"? Are you referring to the v8 releases?

And when you say:

Master releases appear in the beta channel. If a critical bug is not tagged and merged within the incubation period the last release older than the incubation period is moved to the CURRENT channel.

this means that if a critical bug IS tagged and merged within the incubation period then the previous release is NOT moved to the CURRENT channel and the incubation period is extended by the new BETA fix, correct?

Any thoughts on a reasonable incubation period? 10 days? 30 days?

[benjamingr]

• 1000 for this. The way the current release process works is broken and this would go a long way to fix it. I think that time bounds need to be established so stable never falls too far back - we don't want a 0.10 and 0.11 line.

[mikeal]

what do you mean by "we need to do real releases"? Are you referring to the v8 releases?

Real releases of Node. It's hard to build a community round nightlies, having releases you can point people at and get them excited about a feature landing help, which is why I think that Alphas are a good idea.

Any thoughts on a reasonable incubation period? 10 days? 30 days?

The time that was kicked around at Adventure was 2 weeks. I think we can start there and iterate over time as we learn.

[Fishrock123]

The time that was kicked around at Adventure was 2 weeks. I think we can start there and iterate over time as we learn.

I'd like to try starting with one week ala npm. I think it was mostly you kicking around the 2 week thing. :)

[mikeal]

I'd like to try starting with one week ala npm. I think it was mostly you kicking around the 2 week thing. :)

1 week sounds even better.

[aredridel]

I think with the pace of things, 1 week makes a lot of sense.

[Fishrock123]

If we adopt this release process we should scrap our current convergence plan.

Features from 0.12 should converge against io.js master. master should remain at 2.x. No breaking changes can be converged in master and should instead be done on next.

All release lines should rename to "node.js" as soon as possible and development should move to nodejs/node as soon as convergence on master is complete.

@mikeal this is confusing, why?

[mikeal]

@mikeal this is confusing, why?

The current plan calls for us to merge everything for the "next major release" but if we're now saying that we might wait close to a year before a new major we would want to begin putting out new converged node.js releases under the CURRENT channel instead.

[domenic]

A year between new major versions makes no sense. A year between new LTS releases seems fine. Let's be sure to differentiate.

[mikeal]

A year between new major versions makes no sense.

That's about how long it takes for the native module ecosystem to catch up, so it sort of does make sense -- assuming that we have a channel where v8 is adopted on a 6 week cycle and used outside of the major cycle (Alpha releases in the CANARY channel).

[domenic]

Firefox is a good example here. Every 7 versions is a LTS release. But major version bumps every 6 weeks. That's a reasonable model and one we should be following.

[mikeal]

Every 7 versions is a LTS release.

Each one of those 7 releases doesn't break 30% of the websites it tries to render. Those aren't breaking releases -- our problem is that we have major releases with large breaking changes to native modules.

[domenic]

assuming that we have a channel where v8 is adopted on a 6 week cycle and used outside of the major cycle (Alpha releases in the CANARY channel).

Relegating up-to-date, security-bugs-fixed JS VMs to CANARY is not tenable. We should not advertise insecure releases. We should advertise LTS, which gets security work done by the LTS community, and we should advertise current major, which is secure and usable.

our problem is that we have major releases with large breaking changes to native modules.

Yes, that is the definition of major release.

[domenic]

If some native modules only work with LTS, that's fine. That shouldn't slow the pace of major releases.

[mikeal]

@domenic I think you're getting too hung up on version numbers here -- and you're conflating LTS concerns which we previously agreed to remove from this discussion. Can you talk about the users and technical concerns not addressed by this plan?

[domenic]

I don't think I am getting too hung up on version numbers. I think that once you remove LTS concerns there is not much left, so that is why this thread is baffling. This plan seems entirely pointless given a reasonable LTS strategy---so I don't see what users and technical concerns it addresses.

[mikeal]

@domenic the majority of users seem very dissatisfied with the current plan actually, most of them not LTS users.

[domenic]

That's because we don't have a working LTS model yet!

[mikeal]

@domenic I don't think the users we're talking to want LTS releases, they actually want to run current releases where new features and patches land somewhat regularly -- they just don't want things to break all the time.

[domenic]

Users who want native addons not to break, given that according to you native addons take about a year to update, should definitely be running LTS releases with a one-year stability guarantee.

If you think LTS releases should backport feature work in addition to patch, that's a fine discussion to have in the LTS working group, IMO.

[mikeal]

@domenic if the vast majority of users are stuck on LTS that actually isn't good for the project. We need people using newer features on a faster timeline than that for a number of reasons I already outlined. We also need people who want new JS features from v8 adopting those features on a better timeline. We need to do both of those things and those users _should_ represent the majority of users (although possibly not the majority of deployments).

[domenic]

if the vast majority of users are stuck on LTS that actually isn't good for the project

Agreed. I don't see how this has anything to do with what I've been saying, though.

[domenic]

In the end this comes down to security. You have two sources of secure JS VMs:

• The one maintained by the LTS working group
• The one maintained by the V8 team

Everything follows from there.

[mikeal]

@domenic breaking changes landing in CURRENT (both because of lack of incubation and because of native addon breaks) are the biggest barrier to people using CURRENT.

You have two sources of secure JS VMs

How long can we expect major version line of v8 to be maintained by Google?

[domenic]

How long can we expect major version line of v8 to be maintained by Google?

6 weeks.

[mikeal]

6 weeks

It's at least 12 weeks -- they support the currently releases version as well as the upcoming version (this is assuming we are taking the active CANARY version).

But, I've seen them continue some support and patches of older lines longer than that in the past but only for the last major release, the timeline for major releases is totally unclear to me though.

[domenic]

No, upcoming releases are not supported, and neither are past ones. Maybe there have been one-off exceptions on request, but that is done by engineers in their spare (non-Google) time.

The timeline for major releases is every 6 weeks (synced with Chrome).

[mikeal]

@domenic ok, so what you're saying is that if we were to sit on the same version of v8 in the CURRENT channel for a year we'd have to maintain that v8 branch ourselves just like we have to do for LTS? Effectively, CURRENT would have a v8 under LTS while the alpha releases would be pushing supported releases of v8 on the 6 week timeline of Chrome.

[domenic]

Yes. That would take care of the security aspect.

Separately, I think it would be terrible to relegate people who want to use (or write libraries depending on) new language features to a channel designated "alpha." Or people who want a more performant VM, or people who want to use new V8 C++ APIs.

Maybe this is just a branding thing though. Maybe the one that uses a current JS VM would be named "current" or something, whereas the one using a LTS VM would be named "LTS with features" or something.

[mikeal]

Maybe this is just a branding thing though.

I think that it is. On reflection CANARY may not be the best name. The important part is that the channel needs to convey that "You will get great new v8 stuff, you will need to remove your dependence on native modules if you depend on this channel."

[domenic]

+1.

With the caveat that, in the medium-term, I still believe we can do better with native modules and shorten the feedback loop, as discussed elsewhere. (I.e., have releases ready for testing 6-12 weeks in advance, have automated testing and perhaps even automated PRs, etc. so that in theory by the time Chrome rolls some large portion of the native module ecosystem is ready. Plus, V8's list of major upcoming breaking changes is settling down, supposedly, but I know that's not exactly a promise that has much behind it.)

[mikeal]

@domenic so, this proposal is based on three things that are _currently_ the reality but if either change we should consider changing the policy.

• v8 releases, which occur every 6 weeks, will break most native addons.
• most native addons break and require some kind of modification and re-publish when v8 breaks.
• the rough timeline for most of the native ecosystem to catch up is a year.

If any of those things change we should consider a more aggressive major release cycle, and I do think some of them will eventually change.

[mikeal]

To try and reign this in, a few things I think that we agree on:

• master should be released frequently.
• master releases should have an incubation cycle to ensure we don't accidentally cause breakage.
• next should adopt new v8 versions on a 6 week cycle.
• next should be continuously kept up to date with improvements to master

In order to move this forward, let's try to find more things that we can agree on. In order to do that lets stay away from a few things:

• version numbers
• how we market channels and what those channels are called
• releases of branches that are not master or next

We'll figure those out after we agree on some other things.

[mikeal]

Here's a few things I'd like to find agreement on.

• next should not be merged with master on shorter than a one year timeline while it breaks virtually all native addons.
• next should have regular releases, not just nightlies as we've been doing.

[domenic]

Here is my proposal based on the TSC call discussion.

Current setup:

• LTS: used by enterprises. No new features, only bugfixes. Requires us to maintain a V8 fork.
• "master": used by everyone else. Major releases every 6 weeks (in theory). Has problems that spurred this thread.

Proposed setup, using meaningless codenames so as to avoid marketing debates:

• LTS: unchanged (trying not to discuss LTS here as much as possible)
• "A"
  
  
  
  • Similar to current master.
  
  
  • Major releases 6-weekly
  
  
  • Version number increments with every release, like normal.
  
  
  • Has regular "release candidate" or "beta" versions that people test to help us avoid bad things (like breaking changes during what we thought was a patch or minor).
  
  
  • Used by people who:
  
  
  • Are OK with breaking changes, in particular with regard to breaking their native add-ons that do not keep up to the 6-week pace. (Most other breaking changes have been minor.)
  
  
  • Acknowledge that sometimes we might accidentally release a patch/minor with a breaking change, even given the beta safety net. (We'll of course fix this ASAP.)
  
  
  • Want new V8 features/performance/APIs.
  
  
• "B"
  
  
  
  • New.
  
  
  • Major releases yearly.
  
  
  • Each major release picks a version number corresponding to the "A" version that it branches off of.
  
  
  • Requires us to maintain a second V8 fork.
  
  
  • Used by people who:
  
  
  • Want to experience breaking changes approximately once per year
  
  
  • Are never OK with seeing accidental breaking changes
  
  
  • Want to get new features, in addition to just LTS-style bugfixes
  
  
  • Are willing to forgoe V8 improvements
  
  

So people who heavily use native add-ons will use "B" releases, whereas "A" releases are otherwise the best option.

Library authors will then choose which versions they support. E.g. jsdom has a 3.x branch that supports LTS, and a (say) 6.x branch that supports the 2015 "B" release, and then master jsdom will work with "A". But more conservative libraries may want to support LTS onward, or 2015 "B" onward, for an indefinite amount of time.

---

Here's a few things I'd like to find agreement on.

• next should not be merged with master on longer than a one year timeline while it breaks virtually all native addons.

I think this is a process issue for the collaborators to decide, to be honest. So far the spirit for the collaborators seems to prefer master being up to date. So maybe I'd phrase this as "A should not be merged into B on longer than..." and then the collaborators decide where master is A or B.

• next should have regular releases, not just nightlies as we've been doing.

Definitely. In my above this is the release candidate or beta versions of "A".

[mikeal]

@domenic what branches to A and B release from?

[trevnorris]

If you're really going to advocate not merging back down for a full year then I'd say the only practical addition is to cut a version branch and have that be "master". The logistics of merging down a years worth of breaking changes renders it futile. Thus "next" becomes "master", and "master" becomes a version branch (e.g. v3.x).

[domenic]

@mikeal That is what I was getting at with the "I think this is a process issue for the collaborators to decide." Right now master + next together looks most like "A", and there is no branch for "B". Maybe the collaborators would like "B" to be master, and a and a-next to be for "A", but I dunno.

[subfuzion]

@trevnorris that makes a lot more sense to me

[Fishrock123]

I can't read though _all_ off this, but here are some bits that I think are important:

• Current LTS plans are confusing to almost everyone, and this is a lot simpler, which favours the average (and here underrepresented) user.
• Node isn't a web browser, and it would probably be best to not compare it to browsers too much.
  
  
  
  • Web browsers don't do semver anyways
  
  
• Feedback seems to indicate that the majority of the community prefers "stability" (that is, their code not breaking, native or not) over language features and security fixes, and we need to value and respect that.

[mikeal]

@domenic @trevnorris the vast majority of contributions are additive and not breaking. They are small feature additions, bug fixes, and performance changes. Those should go in to master, and the releases those land in should not break 30% of the modules in npm every 6 weeks. That is the entire point of the proposal, to ensure that _most_ contributions find their way to users in a timely manor.

[domenic]

I don't really care what we call the "B" branch. @mikeal wants it to be called master, and that's fine. I don't think branch naming is something we need agreement on.

[mikeal]

@domenic you said B "releases yearly" but I'm suggested we release it as often as we release current now but only with a breaking major release every year.

[domenic]

@mikeal good point, I implicitly meant "releases a new major version" in most places I used the verb "releases" in that post. Will edit for clarity.

[Fishrock123]

the vast majority of contributions are additive and not breaking. They are small feature additions, bug fixes, and performance changes. Those should go in to master, and the releases those land in should not break 30% of the modules in npm every 6 weeks. That is the entire point of the proposal, to ensure that most contributions find their way to users in a timely manor.

+1 to this. I think people will likely have a better time if average patch is able to land in the "current" / yearly* branch. Since we now use semver, we can actually take additions here, which is positive to everyone.

[subfuzion]

Leaving out ALL names for channels and branches aside, these are the three use cases -- and tensions -- I come up against constantly:

1. I want access to a version that is tracking the latest and greatest V8 with all the language goodies, etc, I can get (this is my own personal favorite)
2. I want access to a version that is really up-to-date but not bleeding edge experimental that's going to burn me horribly -- but I don't mind reverting back to a previous release if necessary (this is the one I want most of the time)
3. I want access to a stable version for my enterprise that I can count on has been thoroughly vetted -- rock solid stability is the most important thing to me (this is the one I know I need for quite a few of the organizations I work with).

Now, if I were to personally map that to a branch strategy, I would map 1 to master, 2 to version branches, and mapping to channels, master -> next, version branch -> current, version X -> LTS

[mikeal]

Ok, I think we are approaching agreement on the bigger points.

Let's tackle the version number thing a little bit. There are basically two proposals:

• To increase major version numbers in next on, roughly, a six week time scale.
• To use alpha or some other modifier to next releases until it moves to master.

Messaging wise, it's hard to get people to stop caring about version numbers and use _something else_. On the other hand, if we try to line up version numbers with whatever makes the messaging easier we end bending over backward a bit to get things to line up semantically.

[domenic]

Hmm. These last few comments raise the point that in addition to maintaining a second V8 fork, adding "B" also adds the burden of transferring commits back and forth between "A" and "B".

@Fishrock123 says he prefers transferring commits from "B" to "A", and maybe that's the right direction, but I'm worried that this additional cost is just too much no matter which direction the transfer goes.

Maybe we need better tooling in that regard before we can consider this feasible? E.g. something that automatically transfers commits (and prevents a PR from landing if it can't be auto-transferred). The only alternative I can think of is either making the core team do all the work, or making the contributors do all the work (open two PRs).

[trevnorris]

@mikeal Think you missed my point. "next" is filled with breaking changes, and saying you'll only merge next into master once a year is just bat shit crazy. My proposal was to just change the semantics of the branches to get around that insanity. Otherwise I'd just tell you to force reset the "master" branch on top of "next". Which isn't good for anyone.

[mikeal]

@domenic this already came up a bit as next got a bit stale in terms of keeping up with master. I asked @chrisdickinson how hard it would be to automate this and he was optimistic. The options seem to be:

• rebase next on every master commit
• commit to a weekly (or other entirely time based) release cycle to ensure we regularly bring it up to date.

[subfuzion]

@domenic That came up yesterday and automating sounds like a very good idea

[mikeal]

"next" is filled with breaking changes, and saying you'll only merge next into master once a year is just bat shit crazy.

Right now there is hardly anything in next other than updates to v8. Assuming most of those changes over the course of year step on each other we may just want to do a branch diff and apply it once a year and then reset the next branch.

[domenic]

Messaging wise, it's hard to get people to stop caring about version numbers and use something else.

I don't think it's too bad. Consider: you go to the homepage, and see:

• DOWNLOAD A CHANNEL
  _{v9.2.1, released 2015-10-01}
• DOWNLOAD B CHANNEL
  _{v4.2.1, released 2015-09-20}
  
  

Over a year, you watch the B version number stay in the 4.x range, while the A version number crawls up every 6 weeks. Then at some point B jumps to 12.0.0, and stays in 12.x for another year. Not a big deal.

[subfuzion]

@mikeal I get what you're saying about breaking native modules, but hate the idea of a cycle that seems analogous to an LTS cycle. Are there not any ways of introducing next into current on a shorter cycle than a year?

[mikeal]

@domenic I think I'm coming around to this.

This is about as good a time as any to bring this up: we could call the next releases io.js. We've built a nice following of people who don't mind breaking changes around that brand.

[trevnorris]

@mikeal That's a bad assumption. First, you're looking at a small window of time compared to a full year. The Buffer changes alone for a single release cycle are substantial. Second, we haven't upgraded V8 in next because we haven't got a v3.0 release out yet. Third, ask any one of us what changes we know are coming down the pipe. They're pretty massive. The Maybe/MaybeLocal change alone will require a lot of rewrite.

[mikeal]

@tonypujals there are several ways this might be alleviated in the future but the current reality is that it takes about a year for the native ecosystem to catch up. If we execute on some of these plans that might improve that we'll be able to change the timeline, but I think the level of breakage in the ecosystem should drive this decision and as it improves we should follow it -- not the other way around.

@trevnorris all the changes you've mentioned are related to changes in v8. If there is a branch that we are regularly updating v8 in then that is where those need to go. If we aren't taking a new v8 in to "the branch we point most contributions at: master" then we can't merge those in to master in less than a year. The changes may get massive but what is the alternative other than causing wide scale breakage regularly.

[trevnorris]

Fine. If you insist on "master" being the branch we commit to for "latest stable" then you can handle the yearly merge and everyone else can sit on their hands for the week or more it will take to do that. The task of doing that yearly merge will be fucking huge. Trust me, I've had to do similar.

[subfuzion]

Personally, I don't think it's wrong that master breaks native modules. To me, it makes sense that master is where the latest of everything gets merged. I don't think whatever we call the "stable" channel should be tracking master.

[mikeal]

Draft Channel Names:

• Node.js Enterprise
• Node.js (& Node.js Beta)
• io.js

[subfuzion]

As cool as I think io.js is, I think Next is a better name for the channel.

[mikeal]

@trevnorris keep in mind that master will be getting merged in to next on a regular basis that entire year.

@tonypujals master is where we point most contributions. people want to see those contributions go out in to releases with wide adoption. wide adoption is greatly hindered by breaking all the native modules on a faster timeline then they can catch up.

[mikeal]

@tonypujals next sort of implies it is the "next major version" which is probably not true if we're increasing the major versions in next every six weeks while master remains the same.

[subfuzion]

@mikeal fair enough.

[subfuzion]

(to both points)

[domenic]

@mikeal

• Node.js Stability Edition & Node.js
• Node.js Stability & Node.js Modern
• Node.js & io.js

@trevnorris yeah, I am worried about an ever-growing delta creating maintenance burdens on those working on "next". That is why I think we shouldn't accept PRs unless they land on both master and next. With the right tooling, I think that would end up with:

• In most cases, the patch applies cleanly to both, and so the automatic cherry-picker ports it from master to next with no problem
• In other cases, the automatic cherry-picker complains, and so we don't allow it to be merged into master until the PR submitter creates two separate PRs, one for master and one for next.

Does this seem workable? Maybe not though, as it seems like we could be in a situation where every single C++ PR gets forced down the second path.

[subfuzion]

So those of us in the community who like working on the bleeding edge will follow the io.js channel, which has already become associated with tracking the latest V8 / ES6 features. That actually makes sense: "what Node version are you using?" "io.js 3.0"

I could also see:

• modern
• stable
• enterprise

But io.js works for me...

[subfuzion]

I think the only complaint I have with io.js is that it perpetuates the dichotomy (and angst) between the forks. It feels kinda good to think of it as all "node" now...

[trevnorris]

@domenic The C++ PRs are the more worrisome. I fear it would get to the point where we'd be the ones writing up the same PR for the next branch. Because either it would take significantly longer to explain the changes that need to be made or we want the patch but the author lost interest.

It would be doubly frustrating if the dev spent the time to update the patch for next, then a day later we upgrade V8. Which breaks their patch.

[mikeal]

@tonypujals to use @domenic's earlier example, it would look something like this:

• io.js
  _{node-v9.2.1, released 2015-10-01}
• node.js
  _{node-v4.2.1, released 2015-09-20}
  
  
• node.js enterprise
  _{node-v3.52.1, released 2015-09-20}
  
  

With node-v in each block it make it clear that it's the name of the "channel" and that there isn't a split any longer.

[subfuzion]

@mikeal ah, I like that, actually. Nice.

[mikeal]

Maybe not though, as it seems like we could be in a situation where every single C++ PR gets forced down the second path.

This direction we've talked about moving in towards a more uniform C API between us and the VM would alleviate a lot of this wouldn't it?

[trevnorris]

@mikeal No. The native API discussion is for the native module interface. The internals of node will still use the latest V8 API available.

[mikeal]

In other cases, the automatic cherry-picker complains, and so it can't be merged until the PR submitter creates two separate PRs, one for master and one for next.

This sounds like something we're going to need for LTS releases anyway (although maybe not for _every_ patch).

[mikeal]

@trevnorris I think I'm referencing yet another discussion spurred by the work Microsoft did for binding to Chakra.

[trevnorris]

@mikeal I've been having this discussion at length with them and several other's. It's impossible to create an abstraction that the internals can use without loosing existing functionality. That's a no go. Hence why I brought up the API WG in meeting today for discussion around the two places for user interaction. That's the best they'll get.

[mikeal]

@trevnorris thanks for clarifying :)

[Fishrock123]

In other cases, the automatic cherry-picker complains, and so it can't be merged until the PR submitter creates two separate PRs, one for master and one for next.

I would really not put this sort of burden on people making PRs.

Also, I think it is probably best for the majority of work to land quicker into the current, since it will have most effect there.

However, we could just set up a thing where we simply backport / cherry-pick way more into the current, but that takes a good deal of effort still.

[domenic]

I would really not put this sort of burden on people making PRs.

I mean, it becomes a burden on someone.

[domenic]

This direction we've talked about moving in towards a more uniform C API between us and the VM would alleviate a lot of this wouldn't it?

I mean, if you do that, then there's no need for this whole proposal, since we're no longer breaking native addons every 6 weeks.

[mikeal]

@domenic I think we've pretty much reached agreement here, unless I'm missing something? There are some details to fill in about how we best automate some of the merges but as far as the policy for when v8 lands in each branch and where the regular releases of those branches lands I think we're in agreement.

[trevnorris]

Requiring contributors to create a patch for all V8 versions will be a deterrent. Not only could the V8 version change after they've put in the work, how we use the API itself could cause conflicts. e.g. Our transition to using the Maybe API, or the introduction of using macros for the same.

Sure this will be some more work for us, but we're in a better position to know what changes should be made. My expertise is that API migration isn't complicated when we already know the API differences. And it allows us to more appropriately time when things are migrated.

[domenic]

OK. I think the PR being accepted should be gated on a contributor stepping up to create the counterpart patch though.

[domenic]

@mikeal yeah, at this point it might be reasonable to write up a proposal, and try to recruit people to maintain a second V8 fork, and so on.

[mikeal]

Requiring contributors to create a patch for all V8 versions

How many versions are you referring to when you say "all V8 versions?"

Is the argument here simply between the patch working against the v8 on master _and_ the v8 on next (which may change over the course of the PR) or are we also talking about targeting against other LTS v8 versions?

[trevnorris]

@mikeal Unless it's a security fix LTS won't be a factor. This mainly addresses next and master (was there discussion about having other branches?).

@domenic Sounds good. That will allow much easier timing. For example I have a patch for master to prevent objects with munged proto pointing to Buffer from aborting. But Ben is in the middle of landing 4.4. Which also has significant Buffer changes. I don't think landing the one for master should be conditioned on whether it could land on next.

[mikeal]

@trevnorris ok, cool. The use of "all" just seemed to imply more than two when I read it so I was making sure :)

[trevnorris]

Heh. My bad. Thought I deleted it, but my phone keyboard likes to auto insert stuff. :-P

[bnoordhuis]

Am I the only one who gets terrified by the repeated mentions of automated merging? git merge is profoundly dumb; it happily merges changes that are textually compatible but semantically complete nonsense.

When I do a merge, I use --no-commit and review the diff before I do the actual commit.

[domenic]

Yes, I envision that it's part of the commit process to use (automated tool X) to apply to both branches, and of course preview the results before pushing.

[domenic]

Although it would be better if (automated tool X) would show such a preview on GitHub for review before pushing could occur.

Or if people could just submit two PRs...

[misterdjules]

@mikeal

For the time being 0.10.x is the blessed LTS

Was this discussed by the LTS working group? If so, is there some trace of this discussion somewhere?

[mikeal]

Was this discussed by the LTS working group? If so, is there some trace of this discussion somewhere?

I recall this being discussed way back in the original LTS plan in the dev policy but I’ve been totally out of the loop on LTS since the working group started meeting.

By usage 0.10.x is still the largest install base, so at the very least we need to have LTS releases even if it isn’t the release line we are actively pointing people at.

On Jun 22, 2015, at 2:11PM, Julien Gilli [email protected] wrote:

@mikeal https://github.com/mikeal
For the time being 0.10.x is the blessed LTS

Was this discussed by the LTS working group? If so, is there some trace of this discussion somewhere?

—
Reply to this email directly or view it on GitHub https://github.com/nodejs/io.js/issues/1997#issuecomment-114262948.

[misterdjules]

The LTS working group hasn't started meeting as far as I know, but I'm working on having the first one this week (see https://github.com/nodejs/LTS/issues/6).

v0.10.x usage is larger than v0.12.x usage, but v0.12.x is used by a significant number of users (around 32% from npm numbers posted not too long ago) and could be growing.

I think that, before getting the word out that v0.10.x is the "blessed" LTS version, it would be interesting to get a closer look within the LTS working group at what would be the best candidate for LTS, both in terms of usage and maintainability.

I'll add that to the agenda of the first LTS WG meeting.

[Fishrock123]

@mikeal mind making a bit of a summary or "conclusion so far"?

[rvagg]

This is a weird discussion, instead of removing LTS from the discussion it's just been renamed to "B" and other monikers. I'm now not sure if this discussion is about LTS or a release process, I'm suspecting the real interest here is in how to do an LTS, which again I believe belongs in the LTS WG, not here.

I'd like to suggest that this discussion either be canned or split:

• LTS discussions should move to the LTS WG, there is a meeting tomorrow but there's no way we're going to let that discussion turn into an extension of this one or we'll get nowhere (please don't join if you just have _opinions_ and no resources to actually put in to an LTS, these realise train discussions are some of the most exhaustive that we have in the io.js repo!). There are lots of practical concerns about how on earth we pull off a realistic LTS process that involves 0.10, 0.12 and future work while managing unsupported V8, deciding the threshold of bugfixes to backport, how to version, how long we can realistically expect to support these and who are the people that will be driving the various branches of the LTS efforts.
• Non-LTS release process, as has been hashed out on GitHub a number of times. How do we keep up with V8? How do we manage breakage? How do we deal with addons? How do we version and communicate these things? How do we encourage people to use nightlies and RCs so we get good real-world testing?

[mikeal]

@rvagg LTS is not A or B :)

Here's what we're pretty much agreed on so far.

• next branch takes new v8 releases with high frequency. We cut major releases off the next branch and call them "Node.js Experimental/Future/Next/Io.js" or something. We continue to pull patches from master in to next as often as we can (hopefully doing a better job that we are now, perhaps with some automation).
• master releases on the same schedule it has been in to channel just called "Node.js" and is still where 95%+ of new patches will land and where we point new PRs at. next is only merged in to master once year (we have a little more discussion to be had here about how to manage such a big merge).
• we have another release channel on the main page, called something like "Node.js Enterprise" and that is "whatever the latest release the LTS working group wants us to be promoting" is.

[rvagg]

Love it, :shipit: and close this off eh?

[rvagg]

"Node.js Enterprise" is kind of sucky and mislabelled tho, I think we can do better.

[mikeal]

"Node.js Enterprise" is kind of sucky and mislabelled tho, I think we can do better.

Ya, we all need to stop pretending we're good at marketing :)

[Fishrock123]

Love it, :shipit: and close this off eh?

I do think so? The proposal is technically different to what we've been doing and what we previously agreed upon, and does touch previous LTS proposals.

To be clear, I haven't read everything yet, but I am in favor of this.

Basically it is just shipping majors less often, and merging next less often. Although that does greatly increase the complexity of merging next.

[rvagg]

master does sound like LTS if we're talking a span of years tbh

[rvagg]

s/years/a year/

[cjihrig]

Basically it is just shipping majors less often, and merging next less often. Although that does greatly increase the complexity of merging next.

Any reason not to keep merging master into next, then after a year, next just becomes master? Seems like what would be happening anyway, just with less merging back and forth.

[Fishrock123]

master does sound like LTS if we're talking a span of years tbh

Yes, but it doesn't work the same.

Here most patches would go into that year-long master, with next housing v8 and experimental stuff until it rolls over (but next would also have releases).

It's kind of like a better laid-out more refined version of what node.js was doing previously. But I don't think it's a step backwards.

[Fishrock123]

Any reason not to keep merging master into next, then after a year, next just becomes master? Seems like what would be happening anyway, just with less merging back and forth.

@cjihrig Whatever is easiest I suppose?

[trevnorris]

Overall I like what @mikeal laid out. Except for only merging next to master once a year. Waiting possibly 11 months for a new feature sucks. I'd say at minimum every 6 months.

Think we should clarify a point that there should be no rebases. I am also at fault here, having done it once myself. Last time next was rebased on master we hit a race condition where one dev got the latest and while rebasing another landed a patch onto next. Woke up the next day to find his commit was missing. Basically we either cherry pick all applicable commits or do a merge.

Quick note on critical security patches. When there's a critical security patch that must be shipped immediately I think we should cut a patch release branch from the latest release tag, apply the patch, ship it then merge that branch back into the main branch.

[trevnorris]

then after a year, next just becomes master

I had considered the same. Problem is that requires changing the commit the branch points to. Which is a forceful change and would break everyone's local repos. It needs to be merged.

[Fishrock123]

Waiting possibly 11 months for a new feature sucks. I'd say at minimum every 6 months.

I also find the current proposal slightly long, but I don't think we should major more than once every half-year for the practicality of the majority of the people who actually use node.js.

(Personally 8-10 months sounds most favorable, but it is gut feeling only.)

Think we should clarify a point that there should be no rebases. I am also at fault here, having done it once myself. Last time next was rebased on master we hit a race condition where one dev got the latest and while rebasing another landed a patch onto next.

Shouldn't matter if you've made sure to pull down all the changes?

[trevnorris]

Shouldn't matter if you've made sure to pull down all the changes?

Humans mess up. Also, if we're cutting releases from the branch, which we haven't been doing, then it will need to be tagged. If you rebased the branch head then you'll leave stranded tags all over. Which requires git to track more commits, and makes things like bisecting a bitch. The code of the release I'm running may not be the same as the one at the new, but same, commit from the latest head.

[mikeal]

Waiting possibly 11 months for a new feature sucks. I'd say at minimum every 6 months.

I also find the current proposal slightly long, but I don't think we should major more than once every half-year for the practicality of the majority of the people who actually use node.js.

This is all fungible.

I'll note though that we won't wait "11 months for a new feature" because we will have majors getting cut from next during that period, we just won't be encouraging the entire ecosystem to update, or updating the primary branch we're pointing most contributions at.

A year is just something that is being thrown out there because that's about how long it takes for the native ecosystem to catch up today. What probably makes the most sense is to bring next into master right before a large scale change to v8, which we see about once a year at least.

[trevnorris]

What probably makes the most sense is to bring next into master right before a large scale change to v8, which we see about once a year at least.

Fair enough. Though that does seem to leave open two possible scenarios:

1) We communicate with the V8 team and try to figure out when the majority of breaking changes will land. Though this would probably require releasing at irregular intervals.

2) When it's time to release we merge in the tag from next that precedes the next major round of breaking changes. Which means we won't get the latest V8, but does allow us to release on whatever schedule we choose.

I don't care much either way.

[mikeal]

1) We communicate with the V8 team and try to figure out when the majority of breaking changes will land. Though this would probably require releasing at irregular intervals.

I definitely think we should be seeking to improve communication with the v8. But, to date, these changes have been pretty hard to ignore. This last round, which required a full breaking API change in nan was an obvious one.

2) When it's time to release we merge in the tag from next that precedes the next major round of breaking changes. Which means we won't get the latest V8, but does allow us to release on whatever schedule we choose.

This is probably ideal. We'll want a nice major cycle in next to make sure that nan and the most popular native modules updated successfully before we move it over to the major release channel.

[bnoordhuis]

Can someone give a recap of the current consensus? It seems to have diverged a bit from the original proposal but it's hard to glean because of the thread's epic size.

[mikeal]

@bnoordhuis this is more or less the current consensus https://github.com/nodejs/io.js/issues/1997#issuecomment-116398395

With the caveat that we may change "one year" depending on the circumstances, and the proposed names of the channels are up for debate.

[jasnell]

Ok, question.. I'm trying to understand where this is at but it's difficult based on the length of the thread...

We have next and we have master.
next is where we put breaking v8 changes and really really breaking other changes.
That doesn't mean we still can't have breaking changes land in master does it? Or do we end up only allowing for semver-major changes once per year? i.e. semver-major changes would _only_ occur within next.

[mikeal]

That doesn't mean we still can't have breaking changes land in master does it? Or do we end up only allowing for semver-major changes once per year? i.e. semver-major changes would only occur within next.

Correct, semver-major changes would only happen in next and would only be merged "once a year" (this exact timing is up for debate).

[Fishrock123]

Or do we end up only allowing for semver-major changes once per year? i.e. semver-major changes would only occur within next.

Correct.

Run next sorta how it is today, and only update/cut master from it once every _year_.

master is "stable" or "current" and only bumps majors (using the same version number next is on) once every _year_. Non-breaking, non-experimental (i.e. no flagged features) land in master during that _yearly_ cycle.

[mikeal]

(i.e. no flagged features)

We should be able to land flagged features in master. In fact, it's the best way we can test upcoming breaking changes by making them additive and non-breaking by default.

[jasnell]

Ok, so the next question is: how would this be expected to line up with the LTS strategy (https://github.com/nodejs/LTS/pull/13)? Is the assumption that the highest master major.minor immediately before merging next would become the LTS release? This would mean we'd actually have a 12+18+12 cycle for LTS. That is, 12 months stable, 18 months LTS, 12 months Maintenance.

[mikeal]

Is the assumption that the highest master major.minor immediately before merging next would become the LTS release

Yes.

[jasnell]

Ok. I'm not yet completely sold on the idea yet but it appears workable.

[Fishrock123]

This would mean we'd actually have a 12+18+12 cycle for LTS. That is, 12 months stable, 18 months LTS, 12 months Maintenance.

Using the old system, yes. With this is should be more reasonable to have a shorter LTS before maintenance. (strawman: 6 months non-maintenance LTS, then into maintenance. 12(stable) + 6 + 12 (still 30 months like the original 18 + 12))

[jasnell]

hmm... we're going to have quite a few users who won't pick up the stable _until_ the actual LTS release is cut. Given that, having the 18 month LTS cycle still makes sense.

[Fishrock123]

hmm... we're going to have quite a few users who won't pick up the stable until the actual LTS release is cut. Given that, having the 18 month LTS cycle still makes sense.

Having talked to people at nodeconf, I think those same people wouldn't actually pick up an LTS directly cut from master for a year in the first place. :S

So yeah, you're right there, so long as LTS actually means more than just "maintenance".

[trevnorris]

Please, for the love of version numbers, can we figure out a different versioning method for next? Taking master from v4 to v12 in the merge is confusing and just looks stupid.

[jasnell]

Note to everyone reading: there is a parallel conversation that intersects with this thread going on in the LTS repo (https://github.com/nodejs/LTS/pull/13).

[mikeal]

Please, for the love of version numbers, can we figure out a different versioning method for next? Taking master from v4 to v12 in the merge is confusing and just looks stupid.

People who work on core are following the version numbers on branches but the users are following the version numbers of _releases_ which land in channels they are, for lack of a better term, subscribing to. Sure, we expect most people to pull the channel building from master but we should expect, and frankly _need_, a section of the community pulling from the releases on next which will remain linear.

[trevnorris]

@mikeal I'm not saying that next shouldn't have its own version numbers. If we're going to do releases in a half sane way it will need them. What I'm emphatic about is that master not jump 8 majors between releases. For the most part releases in next will have _nothing_ to do with the releases in master.

This partially stems from the issue that only merging next into master is a ridiculously long delay. Everyone understands that's the same lapse in time the LTS group is proposing, right? So master won't just be LTS-ish. It will basically be LTS.

I have no proposed solutions. Just want to point out:

• Increasing the major version number on the branch that the majority will use is confusing. I don't see how semver semantics fit this proposal. We'd be breaking the API _one time_ on that branch, but would be increasing the major by up to 8.
• A year between merging next to master is far too long. Not only will it make the process of merging difficult, but it prevents more people from testing out new features. Look at the numbers and you'll see anyone who cares that much about API compatibility will choose an actual LTS release. It makes no sense for master to try and achieve the same.

[domenic]

Increasing the major version number on the branch that the majority will use is confusing.

I think it comes down to whether you view next and master as two different products, or two different release lines of the same product. I tend toward the latter, in which case version number jumps for one release line are totally fine.

A year between merging next to master is far too long.

So, this thread started with every 6 weeks (eh, more like 8) being too short. A year is apparently too long. Discuss. (I think every 8 weeks is fine personally, but got shouted down pretty fast on that.)

[trevnorris]

@mikeal Picking up from the LTS thread. We could shorten the release time with some strategic communication and making sure the merge point is the last release of the latest major in next. So master would always be at least one minor release behind latest stable V8.

Reason for this is the increased capability to allow developers to update their modules. If we can have the resources ready (e.g. docs, updated nan, etc.) by the time next updates to the V8 release that will be merged into master then we can give developers 6 weeks to update and test their modules before breaking changes would land.

This seems to be the big pain point now. v3.0 was held back because nan hadn't updated yet. This way nan will have 6 weeks to be updated, then developers have 6 weeks to update.

I'd propose at least twice a year. If we use this type of development cycle then I think once a quarter may be possible. Depending on how the community is able to keep up.

@domenic Sure it may be the same product on two different branches, but next is nothing more than a topic or development branch. Its versioning shouldn't dictate that of the stable release. And since we've basically stated that native modules will be perpetually broken in the next branch, why can't it simply use the next major number in the release cycle for the entirety of its development phase? Its major version shouldn't have to increase with breaking changes. Everyone knows things will break.

Also, if the API WG is able to pull off an ABI compatible layer for native modules then I don't see why a six week release schedule to update V8 isn't possible. It will depend on community uptake, but we could make it happen. Funny enough, it would also mean that updating V8 wouldn't require a major version bump.

[chrisdickinson]

@trevnorris I assumed that we would be merging master into next frequently — likely as soon as changes landed in master — and that this would address the difficulty of merging next in yearly.

Sure it may be the same product on two different branches, but next is nothing more than a topic or development branch.

It's more than a topic or development branch, though — it's a full-fledged release line. To populate this release line, we have to be able to cut releases out of the next branch and put them into the line. We have to do this so that users of that line can install using nave / nvm / n / a package installer on the main site, and so that they know _when_ they should be installing or upgrading. In order for that tooling to work, we have to pick a version number for the release. For the release line concept to work, that version should not be in use by any other release line, and it should increase. Should every release on that next line be 3.0.100, 3.0.101, etc, bumping the patch for each release? The next release on the "stable" line would then have to be 3.0.102 (or 3.1.0), which seems just as arbitrary as a large version bump between releases in a given line.

[trevnorris]

@chrisdickinson Yes we're cutting releases, but it's still a dev branch. Crap will be breaking all the time. Feel free to use the minor and patch all you want, but saying we're going to bump the major for breaking changes on a branch that exists solely to accept all breaking changes seems dumb.

If we want to do what node did before by making every other stable, I can live with that.

[chrisdickinson]

@trevnorris So, if I understand correctly, the worry is that every 6 weeks we'll be taking an automatic major version bump for no reason, in the form of a V8 update? And that consequent to that, major version numbers will impart little meaningful value other than "we merged somewhere between 1 and N separate versions of V8 last year"?

[mikeal]

And that consequent to that, major version numbers will impart little meaningful value other than "we merged somewhere between 1 and N separate versions of V8 last year"?

While it is true that for people close to core these bumps mean relatively small changes they are huge to users because they break so many modules. As far as messaging goes I think it's correct to bump the major while the change effects so many npm modules.

[trevnorris]

@chrisdickinson next is where all breaking changes will land. I'll make the assumption that we'll want to cut releases for next more often than once every six weeks. So if we strictly follow semver it's likely that every release for next will be a major release. If we budge and say, "Oh, we'll only bump for V8 updates" then semver means nothing on next and any versioning incrementation is viable.

My point is, we can expect every release from next to have breaking changes. That's the assumption of the branch. So bumping major for so many releases in next seems futile. Instead I'd at least say next sicks with the same major for an entire development period, and breaking changes can be reflected in the minor while everything else could be reflected in the patch. Then in the merge, master uses the next's major + 1 for its subsequent release.

@mikeal Sorry, not following. We talking about master? I agree that major should be bumped on master with breaking changes. I don't think it's necessary, or even good, to do so on next. The messaging is basically, all breaking changes land here, so make the assumption that stuff will break with every release.

[mikeal]

I agree that major should be bumped on master with breaking changes. I don't think it's necessary, or even good, to do so on next. The messaging is basically, all breaking changes land here, so make the assumption that stuff will break with every release.

Originally I suggested that next stay at one major above master and only produce releases tagged alpha so that we could go through multiple breaking cycles without violating semver. @domenic took issue with that plan as it made it more difficult for people subscribing to the releases on that branch to determine if a release was breaking or not.

[chrisdickinson]

My point is, we can expect every release from next to have breaking changes. That's the assumption of the branch.

One note here: since we're committed to merging master up to next on a exceedingly frequent basis in order to make the yearly next -> master merge feasible, there's a _high_ possibility that not every release of the next branch will contain breaking changes relative to prior releases on that branch. Some may just be integration releases containing commits from master. As @mikeal notes, it's easier for folks on the next branch to track changes if we follow semver universally.

[trevnorris]

@mikeal

Originally I suggested that next stay at one major above master

I agree with that wholeheartedly and believe that whatever versioning solution is chosen, this should be part of it. :)

Version numbers aside, can I get feedback on the 6/6 week preparatory period to releasing a master in order to ease the transition for everyone? I think that plan is enough to get master major releases out every 6 months.

@chrisdickinson Agreed. Not _every_ release will break, but let's say 2-3 in a six week period. If we're committed to using semver in that way we'll be at v50 in two years. I know numbers are cheap and all that, but seriously? Had node.js followed this same schedule we'd be at v200 right now.

Massive version numbers aside, which let me assure you I don't rely on as part of this argument, there are actual drawbacks with this plan.

One is it means new majors on master will not be at regular intervals. It may go from v4, to v18 to v51. This is confusing. Especially to those who aren't involved with the community. We can say community communication needs to improve all we want, but the fact is the project is massively popular. The majority probably only skimmed the website enough to find the download links. I remember explaining the major/minor release schedule to plenty of devs with node.js. This is way worse.

I don't get what would be wrong with setting master on say 4.x and next on something like 5.0.0-N. Sure there will be a few releases that don't break your stuff, but even a merge from master doesn't guarantee that. Unless we cut a release immediately before and after the merge. It doesn't merit incrementing the major on a branch where stuff will break more often than not. Doesn't make sense.

[rvagg]

I reckon we need some in here, something that can replace the top part of this:

I find that so easy to reason about and the only concerning part is the arrows coming down from Unstable to Stable once a year.

[trevnorris]

@rvagg I have a proposed solution loosely outlined in the first couple paragraphs of https://github.com/nodejs/io.js/issues/1997#issuecomment-117472302

Short of it is that internal development, nan and such included, will have 6 weeks to prep for the breaking API. Then module authors are given an additional 6 weeks to prepare before next is merged to master. That amount of leeway should be enough to permit releasing a new major at least every 6 months.

[domenic]

I strongly disagree that next should do breaking releases more often than every six weeks.

[trevnorris]

@domenic That leaves two options. We only release next once every six weeks, or we accumulate breaking patches in GitHub and apply all at once around release time. I guess we could also have a next-breaking-changes branch or the like where patches can be immediately landed, then is merged into next every six weeks.

I don't disagree with the theory of your opinion. I worry about the practically of it since the branch specifically exists for accepting breaking changes.

[domenic]

The former sounds good. Next minus breaking changes is just master.

[Fishrock123]

That leaves two options. We only release next once every six weeks
The former sounds good. Next minus breaking changes is just master.

So what's the versions for this like then? None? it it just like "node.js next v1"..."node.js next v27"...etc? Or?

[domenic]

See https://github.com/nodejs/io.js/issues/1997#issuecomment-112963273

[trevnorris]

I have no objections to that. That will also accommodate getting 6 solid weeks of testing in before the last set of breaking changes are merged into master. Hadn't considered that point prior.

Though we will most likely have to do patch releases of next to fix things we'll inevitably break. So feel like we'd have to cut a patch branch against every breaking release where fixes can land and be released without needing to work around the breaking commits. Thoughts?

[trevnorris]

Still don't agree with bumping next major every six weeks then bumping master all at once. For more reasons then just the size of the integer being used.

[domenic]

Though we will most likely have to do patch releases of next to fix things we'll inevitably break. So feel like we'd have to cut a patch branch against every breaking release where fixes can land and be released without needing to work around the breaking commits. Thoughts?

Yes, I would anticipate a branch for every major version, just like today. And just like today, only the latest released major version will really receive fixes. (Plus master, I guess.)

[domenic]

@trevnorris maybe it would help to look at it from this perspective. The proposal here is basically:

• Keep doing what we're doing, except:
• Rename "io.js" to "Node.js Future" or something cool. Or don't.
• Have a new product, "Node.js Stability Edition" or whatever, and have it be io.js minus any breaking changes (for a period of a year or whatever, at which point it resets).

The rest is logistics around which branch corresponds to which product, and where PRs get targeted. But in terms of what actually happens, it's just what we have now plus a different release line that only "catches up" with the io.js release line every year, in terms of breaking changes.

[trevnorris]

On the side, have we discussed what will happen with version numbers if a security fix happens to break ABI compatibility on master? (i.e. requires modules to be rebuilt)

@domenic That outline seems fine. My concern are the actual version numbers that "Node.js Stability Edition" receives. I believe it's important that, at minimum, the version numbers happen at regular intervals. If we decide that next will update its major every six weeks and, for some god forsaken reason, next is only merged to master once a year then we'd have regular intervals. But as @mikeal suggested, the release cycle could change. The frequency of next to master merge could be altered. If the API working group pulls off an ABI stable abstraction then upgrading V8 may not require bumping major at all. However we decide to version the master branch, it should be shielded from these possible changes.

[domenic]

I think master's major version will bump on major intervals. It just may bump more than one integer at once.

[trevnorris]

master's major bump would not happen at predictable intervals. A six week release cycle does not work well with fixed date releases. One year it could bump by 8 versions, and another by 9.

If we decide that releases should happen twice a year then it will start being bumped by either 4 or 5 versions.

Devs shouldn't need a table to see what releases have been the "stable" ones.

[jasnell]

The LTS WG proposed plan (http://github.com/nodejs/LTS) is using a working assumption of merges from next twice per year (six month interval) with the first happening in early October of this year. Alternatively, the plan could work with four merges per year (13 week interval) but that might not leave enough time for the community to fully test and review any breaking changes that land in the merge just prior to the LTS cut.

The proposed plan also allows for a six month overlap on _Active_ LTS, meaning the current LTS would not go into maintenance until six months after the next LTS is cut.

Right now, based on the current plan, the table would look something like this:

| MAINTENANCE |   LTS    |    BETA    |   CANARY   |
|             |          |  (master)  |   (next)   |
+-------------+----------+------------+------------+
|  v0.10.99   | v0.12.99 |   v2.91.2  |   v3.0.0   |
+-------------+----------+------------+------------+

Once the first converged LTS is cut, it would change to:

| MAINTENANCE |   LTS    |    BETA    |   CANARY   |
|             |          |  (master)  |   (next)   |
+-------------+----------+------------+------------+
|  v0.10.99   | v2.91.2  |   v3.0.0   |   v3.1.1   |
|             | v0.12.99 |            |            |
+-------------+----------+------------+------------+

Six months later it would look something like:

| MAINTENANCE |   LTS    |    BETA    |   CANARY   |
|             |          |  (master)  |   (next)   |
+-------------+----------+------------+------------+
|  v0.12.99   | v2.91.2  |   v4.0.0   |   v4.1.0   |
|  v0.10.99   |          |            |            |
+-------------+----------+------------+------------+

Six months after that, v0.10 falls out of maintenance, and a new LTS is cut:

| MAINTENANCE |   LTS    |    BETA    |   CANARY   |
|             |          |  (master)  |   (next)   |
+-------------+----------+------------+------------+
|  v0.12.99   | v4.20.1  |   v5.0.0   |   v5.2.0   |
|             | v2.91.2  |            |            |
+-------------+----------+------------+------------+

And so on. All the bits shift left every six months, on a regular, predictable schedule.

[rvagg]

Not to bikeshed here too much but 3 merges per year (every 4 months) is also possible. All that LTS cares about is having one fall at the same time every year and to not have the branch that's being taken to LTS be too stale already. Consider that already with a 6-monthly merge, LTS will be taking a version of V8 that's already 6 months old, adding a further 18 months of LTS to that and then an additional 12 months of maintenance, leaving us with having to support a V8 that's 3 years old by the time we decommission it.

There's also the consideration of lining up with V8 releases which are on a 6-weekly cycle, although I'm not too concerned about this given our existing experience there and the fact that it's generally been a difficult process and there will be inevitable delay; plus there's nothing saying that we have to fit exactly to that cycle, we just take it when it's convenient for us.

[trevnorris]

My biggest outstanding concern is how versioning numbers will work. LTS should have predictable numbering, but if master inherits the major from next, and next has plans to do one breaking release every six weeks, then it won't be possible to ensure that the LTS will increase at equal intervals.

[trevnorris]

(continuation from accidental thumb press on phone)

It seems more practical if next had some sort of a different versioning mechanism. Then each merge from next to master can increment the major. This gives LTS the stable release numbering, master the flexibility to decide what latest to merge in (important if we're planning on releasing on dates instead of when features are ready) and lifts a burden from next feeling like it needs to adhere to a strict release schedule. The recent V8 updates have shown that 1) we may just have a hard time keeping up and 2) even V8 has bugs that will affect our ability to make releases happen on a set schedule.

[Qard]

I suggest:

next == semver
LTS == Year.Month.Patch (like Ubuntu)

Then use an explicit LTS tag in the messaging, again like Ubuntu, to
indicate which versioning scheme it follows.
On Jul 14, 2015 12:13 AM, "Trevor Norris" [email protected] wrote:

(continuation from accidental thumb press on phone)

It seems more practical if next had some sort of a different versioning
mechanism. Then each merge from next to master can increment the major.
This gives LTS the stable release numbering, master the flexibility to
decide what latest to merge in (important if we're planning on releasing on
dates instead of when features are ready) and lifts a burden from next
feeling like it needs to adhere to a strict release schedule. The recent V8
updates have shown that 1) we may just have a hard time keeping up and 2)
even V8 has bugs that will affect our ability to make releases happen on a
set schedule.

—
Reply to this email directly or view it on GitHub
https://github.com/nodejs/io.js/issues/1997#issuecomment-121149909.

[rvagg]

LTS just takes over the current major.minor that master is at that time and master merges next and bumps its major to accommodate the new V8. The predictability around LTS is the date that it's released, not the version number. There's also some discussion about using codenames to further differentiate them. But semver would still stick and there wouldn't be any overlap with standard releases.

What happens with next / canary is another matter though...

[trevnorris]

@rvagg

The predictability around LTS is the date that it's released, not the version number.

I don't disagree with you, but don't fully agree either. Having consistent version numbers has several advantages I believe are worth making sure LTS, and hence master, are on a steady cycle.

What happens with next / canary is another matter though...

I assume this implies that you don't believe the mechanism for versioning next / canary doesn't have to follow the same as master.

[aredridel]

What are those advantages?

[Fishrock123]

@trevnorris could you update us on the advantages of consistent version numbers, for posterity?

[trevnorris]

This may seem unimportant, but the appearance of stability. How many software releases of this nature have arbitrarily incremental version numbers? V8 offers no support beyond stable, and users are upgraded without their knowledge. Companies will rely on this to transact billions of dollars, or using it to transfer large amounts of encrypted information. So how does it make sense to tie our versioning to an unstable dependency?

The following pertains more to master than LTS. Steady incremental version numbers are easier to track. Devs can look ahead and know that the following version X will be the one they'll be upgrading to. Or know the major of two versions ago was without looking at a table of releases. I remember responding to devs new to the community about the even odd releases. It will be more difficult to explain there is no pattern, and that they'll need to look at a table.

Now you may say, well they should read the website, but these are devs we're talking about. I wouldn't be surprised if the majority of them clone the repo then find their way onto IRC or the mailing list. And git tags aren't that descriptive about what is a stable release and what isn't.

I can see roadmaps being made for LTS and master releases, and they'll have TBD's all over because no one really knows what the next version will be. For LTS we could just tell them to go look at the periodic table for future names, but this seems a little ridiculous. I can imagine what a whiteboard will look like while engineers are jotting down notes for future upgrades.

This versioning is a mis-conceptualization of what is really happening. We will have releases of next, but breakage in a development branch shouldn't be reflected in a stable release. The only advantage is we get to see how many times the development branch had breaking releases. It doesn't seem a good enough reason to warrant forcing what's happening on next into master.

Though I also disagree that next should only have a breaking release every six weeks. It could be frustrating for a dev who implements a new feature, for a _development_ branch, and it isn't released for up to 6 weeks. The logistics are also complicated. We're going to "maintain" a release branch from the development branch for 6 weeks, just to merge it back in? Or all fixes that land on the development release branch will also have to be cherry-picked onto the development development branch.

There's been discussion about automation, but realistically this will still require human intervention. Discussion has also happened about needing a PR for release and development release. Will we also require a PR for the development development branch as well, or hope that automation will fix it? If there's one place where automation is most likely to fail is on the branch with all the breaking changes. Not even V8 attempts to maintain any sort of stability on their development branch. All changes go under a patch release. Breaking or not.

So I'd say it seems a bit impractical to attempt maintaining release sub-branches of a development branch. Hence more common breakage. Which would require more frequent major updates. Giving even further randomized gaps between stable release versions.

Most of these concern the human aspect of development. Only a few technical notes. Regardless, I believe these are important and worth considering.

[Fishrock123]

Most of these concern the human aspect of development. Only a few technical notes. Regardless, I believe these are important and worth considering.

I agree.

This versioning is a mis-conceptualization of what is really happening. We will have releases of next, but breakage in a development branch shouldn't be reflected in a stable release. The only advantage is we get to see how many times the development branch had breaking releases. It doesn't seem a good enough reason to warrant forcing what's happening on next into master.

Though I also disagree that next should only have a breaking release every six weeks. It could be frustrating for a dev who implements a new feature, for a development branch, and it isn't released for up to 6 weeks. The logistics are also complicated. We're going to "maintain" a release branch from the development branch for 6 weeks, just to merge it back in? Or all fixes that land on the development release branch will also have to be cherry-picked onto the development development branch.

So, there's a little not-so-little problem to solve then. How are we going to version it so that people that want to depend on it or support it alongside "regular" releases, can do so? For example, a package.json's versions field.

I suppose one could stick this all in patch metadata, but that's pretty second class, is there a better way? Can we do like 3-pre-X.Y.Z? I'm not familiar enough with how node-semver works to know..

[cjihrig]

Just a crazy (and half baked) idea, but I figured I'd throw it out there. What if the release number was LTS.major.minor.patch, so LTS releases were predictable, and semver was started from scratch in each new LTS release.

[Fishrock123]

@cjihrig I think it would have to be STABLE.x.y.z, but since the major there is never bumped once in stable... why bother?

[cjihrig]

@Fishrock123 like I said, this was only half baked. My idea would allow development releases to continue on master, but wouldn't work for the LTS team.

[trevnorris]

Another half-baked idea. On next just increment the patch (since breaking changes should be expected anyway). So it starts at 3.0.0, then 3.0.1, etc. When it lands on master it becomes 3.1.0.

[rvagg]

I think the proposal as it stands now should be fairly stable although it would depend on how next/canary is handled.

If we have a 6-monthly next -> master merge and a yearly LTS then we should end up with every LTS taking over every second major version number, at some arbitrary minor and patch. If next is simply x.y.z-alpha.N, regarless of what V8 is included in it, then master would simply be a major version increment every merge, i.e. every 6 months. Then at the end of every second master cycle LTS would take over.

Anyway, this still seems like bikeshedding to me, perhaps you could open an issue @ https://github.com/nodejs/LTS/ and come along to the next LTS meeting next week to hash this out. We've been reaching out to companies that this would affect and haven't had any feedback on version number concern thus far but perhaps if it's raised as a separate issue over @ LTS it might collect some opinions.

[domenic]

So the next releases (which, remember, are going to be marketed as "io.js" or "Node.js Future" or something) don't get proper semantic version numbers? Just relagated to the alpha range?

That's very disappointing.

next is not a development branch for master. It's the fast-paced io.js-style stream for people and libraries (like jsdom, for example) that want to adopt and use new features. It deserves first-class treatment.

[rvagg]

@domenic I'm not asserting an opinion on next, just riffing off the OP where @mikeal proposed that. I personally don't have a hangup on proper versioning all the way up to next and making that flow down to master and LTS. I believe the most important thing for LTS is the predictability around timing of release. Codenames may also help.

[trevnorris]

this still seems like bikeshedding to me

Thing I mainly care about is having consistently incrementing majors on LTS. Which extends to master because LTS will inherit that. The majors don't even have to be sequential.

the next releases (which, remember, are going to be marketed as "io.js" or "Node.js Future" or something

Then not forcing master to inherit next's major shouldn't be a problem. It would be even stranger if master followed after something that wasn't even released under the same name.

And if we are going to do the whole next have its own release branch thing then I'll have to insist it follows its own release policies. Because that basically means a patch for master has to land in 3 places. That'll get hairy fast, because as amazing as our automation may be human intervention will still be required.

That's very disappointing.

I'm sorry? I tried to be very clear why not having consistent incremental majors isn't practical in terms of user experience, but I have yet to see a rebuttal of why making sure we propagate the all powerful semver is more important.

Also I take issue with the fact we're releasing next around V8's schedule. Like it will ever be the only breaking change. But that's for a different discussion.

the most important thing for LTS is the predictability around timing of release.

Before any dismissal of not having consistent majors I would like my discussion points addressed. Which includes issues around using code names for releases.

[domenic]

Then not forcing master to inherit next's major shouldn't be a problem.

It is definitely a problem. Having two release lines with two separate version number trains, which you need a table to correspond, is horrible, especially for developers who want to program constraints or similar. Having next and master share an increasing set of release numbers is done for the same reason we're not just releasing "Node.js 1.0" as the first converged release, but instead going with "whatever io.js is on plus one."

Here is a concrete example:

• In month _n_, Node.js 4.0 is released
• In month _n + 2_, io.js 5.0 is released
• io.js continues with breaking releases every once in a while. Eventually some awesome stuff gets in to version 6.1.
• A developer wants to use this awesome functionality from 6.1+ in his module awesomestuff. He sets a constraint in his docs/package.json/runtime checks/whatever.
• In month _n + 6_, io.js is at 7.2.1, and Node.js is at 4.7.2. Node.js is ready to do a new major release.
  
  
  
  • In your world, Node.js releases 5.0.0. Sad times! awesomestuff still does not work. The awesomestuff developer needs to say "if you're using Node.js, use 5.0+. If you're using io.js, use 6.1+." The awesomestuff developer not only needs to update his docs, but also any package.json constraints, or dynamic checks. Any tooling based around enforcing such constraints (maybe npm, maybe others) needs to branch to accomodate the two different constraint types. Any documentation on the converged project's website needs to include: "this feature is present since: Node.js 5.0+, io.js 6.1+"
  
  
  • In my world, Node.js releases 7.2.1. Everything works! awesomestuff automatically works in Node.js now, not just io.js. The developer might remove a sentence from his docs like "only io.js has released this version yet; wait for the next major Node.js release, estimated in month _n + 6_, if you want to use awesomestuff in Node.js." All tooling can deal with only a single set of release numbers. All docs can just reference a single version constraints. Nobody needs to put together a big table of correspondence.
  
  

but I have yet to see a rebuttal of why making sure we propagate the all powerful semver is more important.

Hopefully the above does that.

[jasnell]

I think I'm starting to come around to @trevnorris' point of view on this. Consider:

If next and master share a common semver, we risk version collisions when we merge from next to master unless we either (a) artificially bump the major in next following the merge, (b) time the merge to coincide with the major bump or (c) time the major bump to coincide with the merge.

Bad:

Better:

Of the three options, (a) means bumping without corresponding changes which violates the semver model, (b) means unpredictable timing which goes against the LTS stability requirements, and (c) means holding major changes until the scheduled merge time. (c) is likely the least bad option.

However, this process also means that absolutely no major bumps can occur in master independent of the merge from next, otherwise we end up stepping all over next. I'm not convinced that we want that. next is intended for really big changes, what if all we want to do is change the default cipher list (for instance), I should not have to wait six months for that to land in master

Bad:

This is not a new problem. The version is a shared resource that needs to be synchronized across multiple threads. Some level of synchronization and locking is required in order for it to work. Synchronization means at least someone is going to be unhappy at some point in the process, either by having to wait to have their stuff land, or by artificially and purposefully diverging from semver.

We can avoid this by allowing next and master to have independent versions. However, this introduces the need to be able to reconcile which version of next maps to which version of master and vice versa. We ought to be able to achieve that fairly easily using tags, but it does mean developers have more to keep track of.

Obviously there are also merges from master into next that aren't being captured in these images but those would be similarly tagged (e.g. tagging a next release with tag:master-v2.4.3, etc). To make it a bit easier for users/developers, we can include the tags in the process.release metadata that @rvagg is proposing in https://github.com/nodejs/io.js/pull/2154:

$ ./node -pe process.release
{
  name: 'nodejs',
  tag: ['next-v4.3.2'],
  ...
}

Yes, this introduces more overhead as @domenic illustrates, but it allows the next and master streams to evolve without blocking or stepping on each other, allows more predictable semver bumps in master addressing some of the concerns @trevnorris is highlighting (with some notable exceptions), and allows for the regular timing of LTS releases.

There are downsides to any of the approaches we choose, but allowing next and master to have their own versions seems to be the least bad approach.

[domenic]

what if all we want to do is change the default cipher list (for instance), I should not have to wait six months for that to land in master

You totally should. It's a breaking change, and we said no breaking changes in master more frequent than every six months.

---

Overall I think your (a), (b), and (c) are not really bad at all. We generally have plenty of breaking changes waiting that can help with (c). The timing on the next -> master merge is probably somewhat flexible (on the order of days or maybe a week), allowing (b) on ocassion. And we might fall back to (a) rarely, but even that's fine per semver spec.

[jasnell]

@domenic ... ok, but allowing next and master to have different versions does not cause problems in your user story above [https://github.com/nodejs/io.js/issues/1997#issuecomment-122002191]. Specifically:

• In month n, master 4.0 is released
• In month n + 2, next 5.0 is released
• next continues with breaking releases every once in a while. Eventually some awesome stuff gets in to version 6.1.
• A developer wants to use this awesome functionality from 6.1+ in his module awesomestuff.
• In month n + 6, next is at 7.2.1, and master is at 4.7.2. Node.js is ready to do a new major release.
• master merges from next and bumps to 5.0.0, which is tagged as being equivalent to next version 6.1.1
• At this point, the awesomestuff module should work with no problem in master version 5.0.0, yes, the developer may need to do a bit more work to document that fact but there are ways of easing that pain (for instance, npm could use the equivalency tags to automatically map out those connections). To be honest, developers building on an unstable branch need to expect a bit of pain anyway.

Also, being forced to wait six months to land breaking changes in master just isn't going to work if that breaking change happens to be part of a critical security fix. It would make absolutely no sense for us to land such changes in LTS and next but not land those in our stable master until potentially months later.

[domenic]

I mean, it causes all the problems of assuming people build an ecosystem and tools around these tags, instead of doing simple version comparisons.

[jasnell]

As I said, there are downsides to each of the proposed options. We aren't going to avoid that and I doubt we're going to come to a perfect solution. In my opinion tho, separating the versioning and leveraging the equivalency tags just seems like the least bad approach.

[mikeal]

Thing I mainly care about is having consistently incrementing majors on LTS. Which extends to master because LTS will inherit that. The majors don't even have to be sequential.

The only way to do this while maintaining proper semver is to stay in the alpha range for next releases. We should probably stop considering any other way to accomplish this because, for all the downsides staying in alpha might cause, they are smaller than the complications involved in creating new non-semver versioning semantics.

The argument here seems polarized but it's actually identical. Both @trevnorris and @domenic are arguing the same thing, that messaging and community building are harder for LTS or next depending on the route we take. A proposal to reduce that burden is to use codenames (either per major or per "blessed" major) and I think that we can soundly evaluate how effective that is for both cases to understand the tradeoffs.

I don't think there is a technical argument here but someone can correct me if I'm missing it. It's easier to reason about semver in both code and messaging but modules are, by and large, not restricted to any semver range of the platform.

Ok, imagine we're using codenames for each of these lines.

Under the @domenic plan those codenames would be how we message each "handoff" from next to master as well as the eventual LTS lines. Semver would increase rapidly on next signaling breaking changes on that branch.

Under the @trevnorris plan the codenames would be used solely for marketing, especially of the next releases. LTS and master releases would be incrementing semver and may be referred to by their codename or their version but next releases would be seen as "Iridium 8" and then next week "Iridium 9" all the way until we're doing "Iridium Betas" and finally a big announcement that "Iridium is stable" and moves over to master. Under the hood "Iridium 8" is "3.0.0-alpha8".

Currently I find the @trevnorris plan more compelling. I think that it's easier to deal with the messaging issues in next than in LTS because of the makeup and size of each community.

This I think is key point: we expect people taking next releases to keep up to date with every bump in the channel, and we have an incentive to keep them from relying on an interim version because it's totally unsupported. We do _not_ expect people using master releases to stay on the "channel" and adopt a major bump immediately, we expect some amount of time to upgrade and we are _actively_ supporting their continued use of that major.

[mikeal]

Ok, time to close this issue. PRs and Issues have been filed for the resolved and unresolved parts of this thread:

• The points we have a consensus on are in this PR: https://github.com/nodejs/dev-policy/pull/74
• Branding Release Channels
• Next branch release versioning

[Fishrock123]

FWIW @nodejs/lts discussed this yesterday and the plan is to have @rvagg and @trevnorris make an updated proposal to discuss / approve this TSC meeting. There are some bits in this currently that do not work well with git.

[mikeal]

Does any of that contradict what is in nodejs/dev-policy#74 ?