New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
lts: strawman LTS cycle #13
Conversation
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 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 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.) |
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.
(...)
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. |
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.) |
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.
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. |
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. |
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. |
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 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 That said, I'm not a fan of the only merging |
Completely agree. I think making |
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 |
@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. |
When that happens, and is adopted widely enough, we'll dramatically change the release policy :)
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 |
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 |
@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:
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
|
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
|
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:
(...)
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:
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 |
write up of the strawman LTS cycle discussed by the WG
on 2015-06-29.
@nodejs/lts @nodejs/tsc