I think we need to define what kinds of changes go in during the different phases. We might want just use LTS as opposed to LTS and maintenance and possibly define along these lines:

LTS - Active - Important fixes as approved by LTS workgroup, critical security and performance fixes
LTS - End of Life - Critical security fixes only

In this context I'd suggest that we only every have 1 release in the "Active" state and as soon as a new LTS release is cut all other LTS versions enter the "End of Life" phase. This would not quite line up with what we discussed in the meeting which was 18 + 12 but if we wanted to maintain the 18 we could make it 12 months "Active" + 18 months "EOL" for a total LTS support length of 30 months.

Personally I like the idea of having that overlapping period on active LTS. It's more work, yes, but it would also provide stability for users who are in transition. That is, many users are not going to jump as soon as the new LTS is cut and may need a transition period to ramp up. For that, the 18+12 cycle works well.

Additionally, In discussing this plan with others inside IBM, the question came up about why it's only 18 months. We've had situations where update cycles stretch out up to 5 years. The key issues, however, are (a) whether Node needs LTS cycles that long and (b) who would actually be doing that work. What I would recommend is that: If specific vendors or members of the community wish to provide additional support beyond the 18+12 cycle, the are welcome to either do so in either their own fork or by petitioning the LTS WG for the ok to contribute fixes back to the end-of-life'd stream.

Also note that following this schedule, new major releases can still occur in the interim period between the annual LTS releases. This regular, incremental cadence would allow developers to begin testing major changes early, well before the LTS incorporating those changes is released.

I'd suggest that adding new/backporting features stops at 12 months. Totally fine with performance improvements, misc fixes, security whatnot, etc., but the continuing heavy usage of v0.10 shows us that most don't care about new features, or don't want to upgrade enough to get them. And, TBH, you'd be surprised how often a new feature that's only additive breaks some random deployment.

@trevnorris ... I'm generally of the opinion that new features should never go into an existing LTS unless it's part of a critical fix. The only changes going into an LTS should be fixes, non-breaking performance improvements. Exception could potentially be given to specific individual changes agreed upon by either the LTS WG or TSC. I've added a second commit that refines some of the details. Please let me know what you think!

I'm generally of the opinion that new features should never go into an existing LTS unless it's part of a critical fix. The only changes going into an LTS should be fixes, non-breaking performance improvements. Exception could potentially be given to specific individual changes agreed upon by either the LTS WG or TSC. I've added a second commit that refines some of the details. Please let me know what you think!

I believe this is the major point contested by the new release proposal ( nodejs/node#1997) (aside from the naming of the release channels).

If our not-(next/fast-v8) branch (here the LTS) could accept features before going into maintenance mode, so that it could be the primary place to land non-breaking/non-experimental changes, that would be great, since that way people who contribute will actually be able to use their contributions broadly, and it will be quickly widely accessible for the ecosystem to use.

(also if we could not plan LTS without the regular release schedule and vice versa that would be great, since they are actually intertwined.)

I believe this is the major point contested by the new release proposal ( nodejs/node#1997) (aside from the naming of the release channels).

That ticket shouldn't be addressing anything in the LTS release policy other than "the LTS WG needs to tell us which release to promote." While master will keep a v8 for a while, which makes it "LTSish," it shouldn't be treated as an LTS release line.

That ticket shouldn't be addressing anything in the LTS release policy other than "the LTS WG needs to tell us which release to promote." While master will keep a v8 for a while, which makes it "LTSish," it shouldn't be treated as an LTS release line.

Right, but this proposal assumes those would be the LTS line(s), or it is definitely worded that way.

1. semver-major bumps are permitted between LTS releases. The LTS release
   will be cut from the then current release. A semver-major bump MUST occur
   immediately following the LTS release so that the LTS release occurs on the
   highest semver-minor in a major stream.

(...)

Let's assume that after this period of time, the
current release version bumps to v4.4.1. The LTS WG decides that it's time
to cut the first converged LTS Release from this version. This
forces a semver-major bump to v5.0.0 in master.

So LTS dictates/is our release schedule? Why is this being discussed separately again?

@Fishrock123 That may only have to do with the phrase "first converged". Right now io.js still has its own releases, and Node.js is maintaining v0.10 and v0.12. That's my guess anyway. There shouldn't be a reason LTS dictates the version numbers of main development.

@jasnell Thanks, I will.

I'm thinking along the same lines as @jasnell. LTS is for fixes. You get new features when you upgrade to the next LTS release.

@Fishrock123 ... No, LTS would be largely independent of the release schedule, but cutting the LTS release would trigger an immediate semver-major bump in master. Major releases could still occur between LTS releases -- in fact, we can have any number of major bumps in between the annual LTS releases. We're talking about this separately again because it was never fully resolved in the dev-policy efforts.

The key reason for forcing a semver-major bump following an LTS release is to ensure that the LTS is cut on the last minor in that stream, simplifying versioning if critical fixes lead to breaking changes. If we do not wish to force a semver-major, then we can make use of build metadata to provide a second level of semver metadata but that just gets complicated.

If we plan our work out properly, aligning the landing of significant major breaking changes with the LTS release shouldn't be too much of a problem.

cutting the LTS release would trigger an immediate semver-major bump in master.

Couldn't we get around this by requiring the LTS group to pick a non-current major?

Couldn't we get around this by requiring the LTS group to pick a non-current major?

Ok, so adjusting to the new release proposal, wouldn't it always be the last stable major? (The one that bumps like, also yearly and average patches would land into.)

I'm thinking along the same lines as @jasnell. LTS is for fixes. You get new features when you upgrade to the next LTS release.

Paradoxically, net-new features introduced in minor changes are safer to adopt than most patch-level changes. Anecdotally, most of the breakage I've seen in io.js has come from patch releases with unforeseen consequences.

Ok, so adjusting to the new release proposal, wouldn't it always be the last stable major? (The one that bumps like, also yearly and average patches would land into.)

I have some catching up to do, evidently :) Yes, if majors only change once a year, then LTS would be essentially required to select the last stable major.

Yes, if majors only change once a year

They would would technically change more, but only in the experimental/fast-v8 branch.

@chrisdickinson ... Potentially, yes, but the effect ends up being the same in the end.

@Fishrock123 ... I still need to come completely up to speed on the new release proposal. Based on what I've heard about it so far, I have some concerns. However, if majors only change once a year, then it would make sense to align that with the LTS cycle so that the LTS is cut on the stable release immediately before that bump.

@chrisdickinson ... Potentially, yes, but the effect ends up being the same in the end.

The end result is the same, but instead of a process we have to remember to do (or the LTS has to remind us to do) to avoid version number overlap, we have a process that automatically precludes version number overlap.

cutting the LTS release would trigger an immediate semver-major bump in master.

But then it's not semver. It's an arbitrary code cut that may not actually mean any breaking changes occurred.

If master is actually going to only merge once a year then LTS should take the last release of the previous major before the next/master merge.

@trevnorris ... yep, I never said it was a perfect solution ;-) ... I've been spending a bit of time this evening going through the nodejs/node#1997 proposal in detail. If we went with the once per calendar year merge from next into master and took the last stable release just prior to that merge as the new LTS, then we end up at the same place. The only questions then become: (a) would that merge from next follow a regular predictable schedule so that the LTS release can be scheduled and (b) Just how "stable" is master during that year long cycle. What changes go into next vs. master over that time and how do we decide. The former is far more interesting from an LTS point of view.

Assuming we adopt the #1997 proposal, the cycle described in this PR would need to change to 12+18+12. That's 12 months incubating as master, followed by 18 months in active LTS, followed by 12 months of Maintenance. With the new LTS entering incubation in master at the point that next is merged.

That said, I'm not a fan of the only merging next once per year idea. It should be several times per year, but with only one per year triggering the LTS cycle. Say, for instance, whenever next bumps majors, the previous next major is merged into master. Doing so ought to shield us a bit more from crazy unexpected version jumps (nodejs/node#1997 (comment)) but it would still be possible to put out an LTS that is several major bumps higher than the previous year (generally no more than the number of next to master merges). IMHO, that's perfectly ok.

I'm not a fan of the only merging next once per year idea.

Completely agree. I think making master a sorta-LTS is a bad idea.

That said, I'm not a fan of the only merging next once per year idea. It should be several times per year, but with only one per year triggering the LTS cycle.

The problem with this is that those merges cause 40% of the modules to break. If those merges stop causing that level of breakage then the release plan will change but the purpose of the current plan is to keep up with v8 on a regular major cycle while avoiding native breakage for the majority of users/contributors who are contributing to and pulling release built from master.

@mikeal Seems like this completely stems from the fact V8 breaks modules. So what happens when there's an officially supported abstraction for module authors to use? We have two working groups tasked with developing an ABI stable abstraction so module authors won't even have to recompile their native add-ons between V8 updates.

Even then, is it really that much of an ask for native module authors to update twice a year? If master merges with the last release of next just before V8 is updated then devs will have 6 weeks to update before breakage happens. That seems like ample time.

Seems like this completely stems from the fact V8 breaks modules. So what happens when there's an officially supported abstraction for module authors to use?

When that happens, and is adopted widely enough, we'll dramatically change the release policy :)

Even then, is it really that much of an ask for native module authors to update twice a year?

Maybe we can get away with twice a year, I'd like to try at least. But we know we can't get away with every 6 weeks, which is what we need to keep up with v8 right now.

@mikeal Agreed that every six weeks is excessive. Twice a year would be great. I'll pick this up on the proposal thread. :)

@trevnorris @mikeal @chrisdickinson @Fishrock123 @nodejs/tsc ... Just pushed another commit update. Keeping the commits separate for now so the deltas between each are clear. Can squash these down if it makes things clearer, however.

The key change in this third commit is to attempt to take the proposed revised release schedule into consideration. It also proposes to shorten the active LTS time for v0.12.

Seems better to me at first glance.

I'm digging it.

One thing I might note in the strawman: a given major version number may be used by only one release channel at any time, including LTS — so this means that for LTS to inherit v3, stable has to become v4 (and next has to become v5.)

In my mind io.js proved the value of having a fast-evolving repo which updated the version number according to code considerations (semver). LTS releases appear to not be tied to code changes, but instead to time ("new LTS release twice a year" and such). So tying the two together seems to propagate requirements of each system into the other.

What about decoupling these systems, by giving the LTS releases names not related to the semver version? Lot's of ways to do this, and none of them will in any way affect the semver of the main line of development, nor cause restrictions/confusions on the LTS versions.

An example might be to stamp the LTS releases by year, such as LTS2015 or if multiple LTS2015A or LTS2015spring, etc.

@drewfish previous discussions were more along that line, and quite frankly it became very, very confusing. :)

@chrisdickinson Does that mean a channel can inherit a major? I like it.

@drewfish Reusing versions is pretty common practice. Ubuntu for example has a release that everyone knows will become LTS after the normal cycle is done.

Some things that stand out for me:

• "performance improvements" is a bit open-ended but I'm not sure how to couch that better; it's clearly not going to be every performance improvement that we could backport, just a select list of major performance improvements that we decide are really worthwhile--in fact I imagine there won't even be many of those because as with semver-minor-type changes they come with lots breakage potential that we only discover when people deploy them in the wild.
• I'm not a fan of the -breaking thing, as @piscisaureus pointed out the -x tag is for pre-releases in proper semver, plus it's noisy and the word "breaking" is sure to be read wrong. I'd side with @chrisdickinson on this one that the uses where these are actually breaking are bound to be bad uses of the API anyway, plus the rareness of having a semver-major come in to an LTS may even warrant just leaving this as "semver-major changes are expected to be very rare but will be landed as semver-minor".
• I don't recall us agreeing that it'd be 18 months LTS plus 12 months maintenance, but I'm cool with this plan as it is anyway.
• As others have already said, "merging next to master once a year" in the release plan sounds like a suboptimal way to deal with the V8 nightmare, but that's a separate discussion to this! Hopefully having this LTS plan mapped out helps those contributing to the release plan discussion have a bit more confidence that breaking the API because of V8 is going to be more manageable because those who really want stability can lean on the LTS releases.

The younger me used to be happy with Debian unstable, then when I swtiched to Ubuntu I'd be upgrading every release. The current, jaded, tired me wouldn't think of using Debian unstable and I don't deploy anything on an Ubuntu other than an LTS because I've been through the pain of being left on an unsupported version. I expect this to play out the same way in Node, that many will be eager for the latest and greatest and be willing to put up with breakage and even help fix that breakage across the ecosystem; while many will simply not want the hassle of having to think about that and will always opt for an LTS.

Yeah, when working it up I realized that we'd left some details out with
regards to how long things would be in active lts vs. maintenance so I
filled in some of the blanks. Feel free to push back if the numbers cause
concern!
On Jul 1, 2015 6:41 PM, "Rod Vagg" notifications@github.com wrote:

Some things that stand out for me:

• "performance improvements" is a bit open-ended but I'm not sure how
  to couch that better; it's clearly not going to be every performance
  improvement that we could backport, just a select list of major performance
  improvements that we decide are really worthwhile--in fact I imagine there
  won't even be many of those because as with semver-minor-type changes they
  come with lots breakage potential that we only discover when people deploy
  them in the wild.
• I'm not a fan of the -breaking thing, as @piscisaureus
  https://github.com/piscisaureus pointed out the -x tag is for
  pre-releases in proper semver, plus it's noisy and the word "breaking" is
  sure to be read wrong. I'd side with @chrisdickinson
  https://github.com/chrisdickinson on this one that the uses where
  these are actually breaking are bound to be bad uses of the API
  anyway, plus the rareness of having a semver-major come in to an LTS may
  even warrant just leaving this as "semver-major changes are expected to be
  very rare but will be landed as semver-minor".
• I don't recall us agreeing that it'd be 18 months LTS plus 12
  months maintenance, but I'm cool with this plan as it is anyway.
• As others have already said, "merging next to master once a year" in
  the release plan sounds like a suboptimal way to deal with the V8
  nightmare, but that's a separate discussion to this! Hopefully having this
  LTS plan mapped out helps those contributing to the release plan discussion
  have a bit more confidence that breaking the API because of V8 is going to
  be more manageable because those who really want stability can lean on the
  LTS releases.

The younger me used to be happy with Debian unstable, then when I swtiched
to Ubuntu I'd be upgrading every release. The current, jaded, tired me
wouldn't think of using Debian unstable and I don't deploy anything on an
Ubuntu other than an LTS because I've been through the pain of being left
on an unsupported version. I expect this to play out the same way in Node,
that many will be eager for the latest and greatest and be willing to put
up with breakage and even help fix that breakage across the ecosystem;
while many will simply not want the hassle of having to think about that
and will always opt for an LTS.

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

@rvagg @nodejs/tsc ... ok, pushed another commit (f7208d3) that removes the -breaking and clarifies some of the changes. Again, I'll squash these down before landing.

This is still a living doc right? As such I'm personally not concerned with hammering out all the details before it's merged. Might actually make it easier to then discuss discrete concerns in separate issues.

Yes, definitely a living document still
On Jul 2, 2015 9:17 AM, "Trevor Norris" notifications@github.com wrote:

This is still a living doc right? As such I'm personally not concerned
with hammering out all the details before it's merged. Might actually make
it easier to then discuss discrete concerns in separate issues.

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

This looks like a great starting point, thank you very much @jasnell!

I would like to echo @drewfish's comment. It feels like we're trying to make the needs of LTS users fit into the semver model. I have the feeling that this would lead to a lot of confusion.

Below are two examples from the current proposal that illustrate that:

The implication of this is that the semver-major bump should be timed to roughly coincide with the regular yearly LTS release schedule.

(...)

Note that while it is possible that critical security and bug fixes may lead to semver-major changes landing within an LTS stream, such situations will be rare and will land as semver-minor bumps.

It seems that, in the current state of this document, LTS releases would not follow semver, and thus would not be usable in system where semver is used to determine what version to use. However, it would:

• Disrupt the non-LTS release cycle by forcing version bumps.
• Require tight coordination between non-LTS releases and LTS-releases.

In other words, we would get none of the benefits of semver, while making releasing non-LTS releases more difficult.

Do we need to use semver to version LTS releases?

I must have completely missed something, but won't LTS branches stick to the same major for their lifetime?

Yes, the major will never change for an LTS branch.

Going to get this PR landed now... recognizing, however, that it's still a work-in-progress strawman that has not yet been ratified. Feel free to keep the conversation going here or to raise specific issues in the tracker