Proposal: New Release Model

[jasnell]

/cc @nodejs/releasers @nodejs/tsc

Our current Node.js release model is... complex.

• Rather than a single Semantic Version stream, we currently have four, one for the HEAD, and one each for the current Long Term Support branches. This makes multiple things fairly complicated. For instance, understanding when a new feature was actually introduced -- in the documentation, we end up with metadata saying that a feature was introduced in 15.x, 14.x, 13.x, 12.x, etc ... with the versions reflecting whatever downstream version is happens to have been backported to. This makes it extremely difficult to reason about what Node.js versions has a given feature.

• Cutting a new release is... complicated. In addition to the main branch, we have Release and Staging branches for each downlevel LTS stream (so, currently, there are 9 separate branches for HEAD, 15.x-staging, 15.x, 14.x-staging, 14.x, 12.x-staging, 12.x, 10.x-staging, 10.x, not to mention the private github organization and branches we use for security triage. Backporting changes from one to the other is complex, with significant and inconsistent lag times in when various features make their way back to older Node.js versions. Sometimes useful features never get backported, other times the simplest oddest things easily jump back multiple Node.js version levels. Backporting is made even more complex by dependencies of semver-patch and semver-minor commits on prior semver-major commits, and we've had quite a few cases over the years where documentation bugs have crept up because some doc change was backported when it shouldn't have been because the underlying feature hadn't actually been backported yet or was based on a semver-major change.

• Cutting a new release is... time consuming. Folks preparing a new release have to curate a set of commits back first to staging, then to a working proposed release branch, then to the actual release branch, then reconcile that back to both the staging branch and the HEAD branch, updating release metadata in the process.

I could keep listing issues but anyone who has gone through the process of cutting a new Node.js release already knows that the process is difficult and time consuming.

I'd like to propose a change detailed here: https://docs.google.com/presentation/d/13JkM4SLm176XE92pIiDSNtx-MMY2v7eLs9b_qzSc8DA/edit?usp=sharing

I'm sure there are going to be lots of questions and things to discuss. What I ask right at the start is that you please ask questions to clarify before commenting or offering opinions.

The short version is this:

We switch to a Canary / Current / Stable model.

Canary releases are automatic and weekly. Once per week, the current HEAD is automatically rolled into an updated Canary release. All semantic versioning happens only in the Canary stream, with semver-major and semver-minor bumps happening as necessary as things land. The Canary releases are tagged as {major}.{minor}.{patch}-{datestamp}-canary.

Current releases involve nothing more than taking an existing candidate canary tag and promoting it (with a few additional metadata bits) as a new current tag. There's no selection of commits into a release. We take the existing canary tag, update the metadata with a commit, and tag it with a new current tag {major}.{minor}.{patch}-{datestamp}-current, where the {major}.{minor}.{patch} does not change. A new current can be promoted at any time but would happen at least once per month.

Similarly, Stable releases involve nothing more than taking an existing candidate current tag and promoting it (also with additional metadata bits) as a new stable tag. There's no selection of commits into a release. We take the existing current tag, update the metadata with a commit, and tag it with a new stable tag {major}.{minor}.{patch}-{datestamp}-stable, where the {major}.{minor}.{patch} does not change. New stables can be promoted at any time but would happen at least twice per year.

Current release tags are never updated. If new features, bug fixes, security vulnerabilities occur, we land those first in the HEAD, cut a new canary tag, and promote a new current tag. There is no backport flow to current, ever.

Stable release tags only ever receive targeted critical security and bug fixes applied as patch sets that only update the build metadata (the {datestamp}). There is no backport flow for semver-minor or semver-patch changes that are not considered critical bug fixes.

One Stable release tag per year would be selected for 3 years of Long Term Support effective from the day the tag is promoted. This would be maintenance only subject to the backport rule just described. Specifically, LTS stables would never receive anything more than critical security and bug fixes.

This approach offers a number of important benefits:

• Eliminates Active LTS. The Active LTS cycle has been difficult and complex due to the backporting flow. It also increases the risk of taking on breaking changes and increases the complexity of our branch and version management issues. Eliminating Active LTS is, by itself, a net positive.

• Eliminates persistent staging and down-level release branches. Patch sets to update maintenance for critical bug and security fixes done in transient working branches with PR back to tag when ready (similar to the way GitHub's new security advisory workflow works... in fact, we'd be better positioned to use that mechanism with this new approach). Importantly, we could eliminate the multi-branch staging-release structure we have now.

• Simplifies current release process by eliminating the "backport and cherry-pick a bunch of commits into a staging branch" part of the flow.

• Eliminates the multi-stream semver model we use now. Maintenance updates will bump build metadata rather than version. All semver happens on canary stream only. Make version numbers less important for maintenance.

• Eliminates backporting of new features. This does mean that users may have to take on breaking updates to get new features but the overall maintenance burden is reduced.

• Decouples the release process from any reliance on the specific semver number (semver numbers become far less important overall).

• Allows taking on new V8 versions more rapidly, gaining new features and fixes at a faster pace. These would flow naturally through canary and into current releases, promoting into stable approximately twice per year.

• It preserves existing Long Term Support timelines. Just like now, there would be one guaranteed stable release per year that would receive three years of guaranteed support.

• It simplifies changelog management and reasoning about when features are added. Since features are never backported, they are only ever added to a single specific Node.js version.

• It does mean that semver-major bumps could happen as often as every week but this approach eliminates the focus on specific Node.js version numbers and instead focuses on the Stream and the datestamp. Enterprises that want stable Node.js versions to build on would select a Stable tag covered by LTS. Developers that want the newest features frequently would select the latest Current. Developers who want to live on the cutting edge would select the latest Canary. The specific semantic version associated with any specific tag just becomes additional build metadata.

• It does mean that users will not receive new features without also taking on potentially breaking changes. This is a key trade off. New features roll out faster in Canary and Current, but never into existing Stables.

The reference google slides (https://docs.google.com/presentation/d/13JkM4SLm176XE92pIiDSNtx-MMY2v7eLs9b_qzSc8DA/edit#slide=id.gbaf0f0fe08_8_20) include a number of other questions and discussion points that have come up from folks. Before weighing in on this proposal, I ask that you please take a look through the slide deck and formulate any questions that you may have about the proposal.

I'd like to keep the discussion focused and moderated as I'm sure there are many Strongly Held Opinions. Let's start first with clarifying questions before we move on to debate.

[wesleytodd]

How would this new release process work for a package author in this scenario?

1. They have committed to supporting active_lts in the current model and would like to give their users a similar commitment going forward
2. The new release process is introduced
3. They have a compelling reason to adopt a new feature introduced in a node version under the new release plan

I see two possible outcomes:

1. They major version rev their package, drop support for existing versions and require users to update (the most common way package authors work with major lines today).
2. They are now responsible for supporting many more major version lines (one per week at most) of their package to support their users.

The problem with number 1 is those older lines are never going to get security and bug patches. In order for users to update they also are required to take on breaking changes in node. Imagine a slow to update native dep (hard to imagine right :P) along side a package which updates for new node features then has a CVE on all previous versions. In this case a user cannot take on new security patch of one package because the are unable to update node versions because of the broken native dep.

The problem with number 2 is that we have greatly increased the workload on package maintainers, with all the rather obvious issues related work offered freely.

I don't think the current release process is without these type of issues, but also the edges are more well known in the community and node breaking changes are slow enough to keep up. This new way sounds like it has more risk of these types of issues appearing.

[jasnell]

I'm not convinced that the proposal increases the burden at all, in reality. Think about the CI support matrix we already have, and the delta that already exists between Node.js major versions. Package developers that wish to support multiple Node.js version lines already have to deal with potential breaking changes between those, and existing packages that do wish to support multiple Node.js release lines rarely adopt new Node.js features without clearly signaling breaking changes or leveraging polyfills.

Under the current model, if an existing package wishes to take on a new feature introduced in a new Node.js version, they cannot depend on that feature existing in any backlevel Node.js version unless it just so happens to get backported in a new release under that old line. That backporting is extremely hit and miss and inconsistent and could end up introducing just as many breaking changes as actual semver-major changes. Bottom-line is that the proposed process does not introduce any new problem into the mix. It actually simplifies a bit by saying: if you want a new feature in an old Node.js release line, you will have to depend on polyfills because it will not be backported.

To be honest, I think we collectively put too much emphasis on the specific semver major number. We tend to see Node.js 16.0 as less of a breaking change over Node.js 15.0 than a Node.js 20 would, completely ignoring the actual number of semver-major changes that may have landed or the nature of those. The semver number is just a number, and the numbers aren't actually that important. From a package developer point of view, target the Current releases, not the Canary. Test with a selected baseline Current and with the most recent Current. That gives you the minimum feature set you know you require and the most recent changes to make sure you haven't been broken.

[wesleytodd]

Bottom-line is that the proposed process does not introduce any new problem into the mix

I am still not positive on this. I think that many backported features have worked out fine in all but edge cases.

if you want a new feature in an old Node.js release line, you will have to depend on polyfills because it will not be backported.

That could be a solution. I wonder if this does not mean we will have a readable-stream type situation forever in that case, where you are just required to load in X number of polyfills in all libraries to achieve compatibility. I don't know this is the future we want.

completely ignoring the actual number of semver-major changes that may have landed or the nature of those.

I completely agree on this point from a theoretical point of view, but in actuality when a team is ready to upgrade majors they set aside time to deal with the breakage. I think this is fairly equivalent between the two release approaches assuming we can resolve other questions well.

---

In the end, I think what is important is that any change can be well communicated so that teams and individuals know what to expect and what this change would mean to them. If that can be done I don't think people are too opinionated (I mean general "people" here, not the ones in this thread) and will be fine with the decision either way.

[jasnell]

That could be a solution. I wonder if this does not mean we will have a readable-stream type situation forever in that case, where you are just required to load in X number of polyfills in all libraries to achieve compatibility. I don't know this is the future we want.

Possibly, yes. This is a tradeoff, but it exists in everything we do. How long, for instance, will the abort-controller module exist on npm and be used actively by projects now that AbortController is native in Node.js? regardless of whether we back port it? Back porting a new feature does not mean that the polyfills for it suddenly stop being used.

[Trott]

Is it possible to devise an incremental approach to going from where we are now to something like this proposal? I think the answer is "no, not really", but if I'm wrong about that, I'd be interested to know what the first incremental step or steps might be.

[jasnell]

Possibly, yes, But before we break it down into incremental steps let's try to agree on where we're stepping to so we can make sure we're heading the right direction.

[bnb]

After some discussion with James's thread on Twitter with the intent to respect his request to fully parse and ask questions before sharing opinions, I... want to share opinions.

My perception so far is that this proposal... changes the mental burden on users without meaningfully improving it.

Specifically, we're extending a ecosystem standard paradigm with our own special context that they'll need to learn just for us. I... am concerned about putting the burden on our users - who have consistently voiced that the current system is too confusing - rather than finding an avenue to manage this from our side of the release process.

I do think that the proposed system could be beneficial in reducing the burden on releasers and help increase the project's velocity. I am just... extremely cautious about the potential putting additional burden on the ecosystem and our users with little tangible benefit to them.

[jasnell]

Addressing the point further here... So long as a revised versioning system does not make things more difficult for users, then I do not think that not providing additional benefit to users is a strike against this proposal. Ideally our users wouldn't have to think in terms of Node.js versions at all -- at least, not any more so than they have to think about what specific version of Chrome they are using, for instance. Even on the Node.js website we attempt to make the choice as easy as possible for users, presenting only two options for downloading Node.js...

What difference does it make to users if we removed the semver-version numbers from those buttons but still presented the equivalent options? Either you get the LTS version or the Current version -- the version that is most stable, or the version that is potentially unstable.

There's no reason at all why the end users need to be confused by whatever versioning scheme we use if there's no reason for them to care about what the version scheme is.

Now, I'm very specifically talking about the end users here. As has been pointed out and acknowledged in the discussion, it's a different story for package authors that have the need to support a range of Node.js versions. They have to pay attention to the Node.js version and we cannot hide it from them.

For those, under the new scheme, the support matrix actually becomes fairly simple:

• Support the LTS Maintenance tags.
• Select a base-line Current tag such that the package supports every version beyond that tag. Then in CI, test against your baseline and against the most recent.
• Ignore canary unless you really want to get into early warning.

Under the new scheme, existing mechanisms such as the "engine" tag in the package.json remain just as relevant as they are today. That is, you could baseline on a specific Node.js {major}.{minor}.{patch}. None of that existing mechanism is impacted here.

The only additional risk to package authors is that breaking changes could enter the current releases as quick as once a month as opposed to only once every six months. The number of such changes from one release to the next will be much smaller than the accumulated number every six months. Note that we can also revert such changes must faster under this new model as well.

If you dig through the actual collection of semver-major changes that typically come through, precious few of them are actually breaking, and if they are serious enough we already go through an do breaking reverts or fixes without bumping majors. However, there's little evidence that semver majors we do land actually cause widespread breakage in the ecosystem. Sure, we can always find an example of where they did, but that's why Revert is always on the table.

Given this, putting discussions about support for things like ESM and N-API aside for just a moment, it's not clear that the new scheme would actually make anything worse for package authors either. Nor would it require a massive departure from their current support model. A package either supports a given feature set from a specific Node.js version or it doesn't. The suggestion that package authors would suddenly have to start testing on a larger matrix of Node.js versions is not correct.

So again, if the new proposal does not make things worse for that particular group of users, the fact that it might also not improve things is not disqualifying.

[ljharb]

Package authors always (with or without this proposal) have to test on every node version they support. Many authors choose not to - they test on "latest 12", for example, despite supporting >= 12.0.0 in "engines" - but for authors that prefer to test all supported versions, "more versions" absolutely means "more testing".

For the authors that do not choose this, "more versions" only means "more difficult bug triage".

[jasnell]

Yes, but the suggestion is that the new proposal will somehow explode the complexity of that testing matrix out, when that is simply not the case. Assuming that package authors are focusing on the Current and Maintenance tags (that is, those tags are the versions they are supporting) as opposed to the specific semver number, and assuming those Currents are coming out once a month, then that's 12 new versions a year (approximately). There's simply no need to test every single semver-version that comes out in the Canary stream because users won't be using every single semver-version that comes out in the Canary stream.

In comparison, so far, there have already been 14 versions of 15.x since October 2020, and 7 LTS versions of 14.x since it was minted LTS in October, and 21 versions of 12.x LTS since it was minted as LTS. The support matrix is already complicated.

The proposed new model does not make it any more so.

[ljharb]

One complication that this proposal increases is that there's tons of existing systems built around the current system: i have a shared travis-ci config and github actions matrix action for testing node versions, nvm and other version managers are built around it, etc. Even if the ongoing complexity would be the same, the complexity of transitioning is quite large.

[jasnell]

We would certainly need to identify the ways in which such systems could break, if at all. Certainly installers like nvm would need to be updated to use the new scheme.

[BethGriggs]

I have read the proposal through several times and asked a few questions, but as someone who has shouldered a reasonable portion of the release work recently, I’d like to share some $thoughts.

While I agree that the release process can be time-consuming/demanding, I don’t believe the biggest pain points are solved by the new proposal, while it has significant impact on end-users.

$thoughts:

• Canary - Semver-major bumps could happen as often as every week
  • Is this what our users desire? I’d have thought if users want to be this close to HEAD, then I’d have thought we would see more requests/downloads/uptake of our nightly builds.
  • For Canary and Current, we can expect more regular breaking changes. When we introduce breakage in the Current release line, our users report it and we revert or fix it. There’s an existing expectation for Current that it does not have major breaking changes. Changing this expectation would be a challenge - and offering users the option of dealing with regular breaking changes or no new feature additions doesn’t seem fair (IMHO).
• Eliminating Active LTS
  • Previously, we have sought to backport as much of what we can to make backporting easier in the future by reducing the divergence (with security/critical fixes in mind).
  • This would eliminate the backporting of new features. But for many new features, backporting to LTS has been crucial for adoption or easing migration (ESM, for example).
• Backporting security fixes to LTS release lines
  • This is mostly a challenge because of the delta/divergence between the release lines over time which means a bespoke security patch is needed for the earlier LTS versions. I don’t believe this proposal will make that aspect easier, as the delta/divergence between the Canary, Current, and Stable will still exist (and I believe is likely to be slightly larger as it may include more breaking changes). We could still have almost ~3-years worth of divergence between Canary/Current and Stable.
• Branch management
  • I have not seen our branch management as a burden during the release process. In the new approach, I believe we’d have to create a temporary/working {major}.{minor}.{patch}-{datestamp}-stable proposal branch for the next release. Does that mean when contributors are trying to target a fix to a Stable line, they have to go find the latest datestamp of that version and open a PR against that? That on the surface appears to be more complex than having a branch that is always vN.x-staging that contributors can target.

The key benefits of the proposal read to me as being mostly to the maintainers/Node.js core developers. It allows Node.js core developers to get their breaking changes out in releases quicker and aims to reduce the burden on releasers. (Although, I don’t believe the proposed model would significantly solve the key challenges I see as a releaser.). I agree with @bnb's thoughts that this will add a burden on the ecosystem and our users with little tangible benefit to them.

Is it possible to devise an incremental approach to going from where we are now to something like this proposal?

As an incremental step, we could preserve most of the current model and start by dropping the ‘Active LTS’ phase for Node.js 16. That would give some time to confirm some of the proposed benefits - such as whether it makes maintenance easier, reduces the burden on releasers, etc. But would also allow us and end-users time to determine the benefits/consequences of not receiving new features in LTS/Stable version.

[jasnell]

The question however, is will the ecosystem as a whole look to adopt only ESM in 12.x and 14.x (for example) or will it do so in combination with other key language features that may not be available. Top level await, for instance. The question about package authors is legitimate, and one that I am definitely considering to see if there is a good answer for, but in terms of end users, the trend I see more is to not take on the new features until they can do so en masse, combining with other new features -- and that kind of transition only happens when taking on new LTS versions (as opposed to evolving around existing ones).

Either way, the points that have been made about ESM (and N-API) adoption are valid discussion points that I'm taking back to consider, so I appreciate the discussion. What I'm less convinced about, however, is that we have sufficient evidence at hand to drive us towards one decision or the other.

[bnb]

The question however, is will the ecosystem as a whole look to adopt only ESM in 12.x and 14.x (for example) or will it do so in combination with other key language features that may not be available.

For what it's worth, I don't think any feature will be adopted by the ecosystem as a monolith, especially one as... unique as ESM. This kind of change will take years to become "standard". Backporting and getting older consumers in a position where they can use it enables maintainers to adopt it sooner than starting to ~3 years out when every single version of Node.js that's 'supported' has support for the feature.

[jasnell]

Yeah I understand the argument there but let's look at it a different way. The module ecosystem could adopt ESM today without it having been backported to 12.x and 14.x by leveraging the dual mode support that we've baked in. I'll use my own Piscina module as an example. It supports both commonjs and ESM, derived from a single codebase. Users on down level Node.js versions that don't support ESM could, at least theoretically, use it with no problem (theoretically because it happens to use other features that only exist in newer Node.js versions). The plan for Piscina is to slowly phase out the commonjs support over time as those older Node.js versions reach end of life.

I don't believe we yet have enough empirical evidence to claim that backporting ESM to the older lines accelerates it's adoption in the ecosystem.

[ljharb]

ESM is a special case, unlike most other features, since it's related to the module system and is designed to accommodate the dual module case you're referring to. A new API on a core module, or new syntax provided by v8, would be examples of features where backporting empirically accelerates adoption.

[jasnell]

Hmm... with exception given to very selective cherry picks and bug fixes, we don't backport V8 updates into LTS at all, Active or otherwise, and therefore don't backport new syntax provided by v8. Such updates can happen in Current, yes, but not in LTS. New APIs on core modules can and have been backported, yes, but doing so is inconsistent and module developers that commit to supporting the full range of LTS versions still have to be prepared for those features not to exist there. I think we'd need far more study to say conclusively whether backporting such features actually moves the needle on their adoption.

[MylesBorins]

This proposal feels a bit to me like a solution looking for a problem.

A quick summary of what I see as the identified as the problems being solved for and proposed advantages

Problems

• Releases are hard to do and take too much time
• V8 updates don't get out in a timely fashion
• Current release streams can be confusing to both collaborators and consumers

Proposed Advantages

• No backports
• Streamlined process
• Streamlined consumption
• Releasing V8 faster

---

There are a variety of new problems that I think this proposed process will introduced, and a variety of threads above where folks have pointed them out... so I'm going to focus more on the proposed problems and advantage and why I am not convinced by this proposal (although I am not outright dismissing it)

Time for releases

While doing releases can be time intensive, I have not heard the release team asking for this level of radical change. The team right now is the healthiest it has ever been and to the best of my knowledge I have not heard community complaints about the projects ability to ship releases. There are a variety of smaller iterations we could explore including shorter Active LTS cycles (we only just switched Node.js 14 to 12 months and haven't even finished our first round of this new timeline), being less aggressive with backports, or even changing the cadence of releases.

I am not convinced that we need to make this radical a change to improve the process nor am I convinced the process needs much change at this point as we appear to be adequately staffed with volunteers.

Updating V8 is Slow

We run into issues keeping V8 up to date on master because integration is hard. If folks want the latest and greatest V8 they can already download a nightly, which doesn't appear to be substantially different than what "canary" is in the proposed model.

As @BethGriggs mentioned above we don't see very large adoption of our nightly releases. Perhaps that is a problem with our nightlies. A focused effort on improving adoption of nightly releases seems like it could be worth investing in.

Current release streams can be confusing to both collaborators and consumers

I'm not convinced that this is as large of an issue as presented, nor am I convinced that the radically different proposal is substantially better. As mentioned above we utilize Semver and the fact that we support multiple "LTS" lines is the source of the extra labor and confusion. Having less "modes", e.g. no active LTS seems like a far less disruptive change that would have very similar desired outcomes to this proposal. With that said I think the active LTS has been extremely important in supporting module authors and would be skeptical about removing it.

---

As for the advantages

there will still be backports, just less
I don't believe the process is streamlined, just different
I don't believe that consumption is streamlined, just different
I don't believe there is any actual change to the shipping rate of V8, just a different name for nightly.

---

Overall I'm -1 on this, while I do appreciate the effort and thought that went in to it . I'd like to see much clearer identification of the problems being solved as well as much clearer advocacy from the groups the proposal claims to be supporting (release managers, module authors, node.js developers).

[jasnell]

I would ask that we not get into -1 +1 type of "voting" on this right now. This is a discussion and there's a lot to discuss before we get to the point of decision making... otherwise we risk dog piling and shutting down discussion. There's nothing in this proposal that is all or nothing.

[jasnell]

Dealing with a few points directly.

have not heard the release team asking for this level of radical change

I am still a member of the release team officially but I haven't volunteered to do a release in a while and intentionally stepped back away from doing the major releases because of the amount of time it takes and the complexity of the current process... so consider this to be a member of the "release team asking for this level of radical change." I'd be much more likely to re-engage with releases if the release process were greatly simplified relative to what it is now.

That said, I opened this discussion not really to push a single canned proposal but to start a conversation about what changes we could make that would be of benefit to everyone. There's already been some excellent feedback and good questions raised.

[MylesBorins]

Apologies for both the -1 and for implying that you are not part of the release team. Framing it that way was short sighted.

[jasnell]

Addressing a few more discussion points:

While doing releases can be time intensive, I have not heard the release team asking for this level of radical change. The team right now is the healthiest it has ever been and to the best of my knowledge I have not heard community complaints about the projects ability to ship releases.

While that may be true, none of this speaks to the actual complexity of the process. Sure, we may have plenty of folks willing to go through the steps but that doesn't mean the steps can't be simplified and optimized further.

We run into issues keeping V8 up to date on master because integration is hard. If folks want the latest and greatest V8 they can already download a nightly, which doesn't appear to be substantially different than what "canary" is in the proposed model.

Folks don't download and use nightly because we tell them not to and nightlies aren't considered official releases. They're not front and center and no actual end user is going to go out and download a new version every day given that there is no automated download and upgrade process. I wouldn't expect end users to download the canary releases that often in the new model either. They are there as part of the process, but they are not the focus.

Yes, V8 integration is hard, but that's only one small part of what I'm talking about. I would like to be able to get V8 updates out as soon as they are ready, rather than only once every six months. If we were better able to track the V8 releases, we could avoid the kind of ABI stability hacks we've had to include in order to bump V8 versions in the past -- but even that is not the core point, it's just an additional benefit.

The core point for me is in getting changes out to the ecosystem faster and more incrementally than we currently do while also simplifying the release and versioning scheme.

As @BethGriggs mentioned above we don't see very large adoption of our nightly releases. Perhaps that is a problem with our nightlies. A focused effort on improving adoption of nightly releases seems like it could be worth investing in.

Focusing on nightlies / canaries is the missing the point. Under any scheme, we don't need to focus on those or whether users make use of them. Under the new scheme they are simply part of the mechanism of producing new releases and managing the version flow. They can be used by folks on the bleeding edge to detect issues (possibly even replacing the need for CITGM, which would also help simplify things for us), but that is optional and is not what we should focus on here.

Several folks in several conversations have brought up the fact that nightlies aren't used so I just want to be clear: I couldn't care less about the nightlies.

With that said I think the active LTS has been extremely important in supporting module authors and would be skeptical about removing it.

I think this deserves additional study before we can stipulate it. I'm simply not as convinced that the Active LTS has been actually as important as suggested -- at least for anything other than entirely new subsystems like N-API and ESM -- both of which merit review and consideration.

[mhdawson]

Had a chat with James to clarify what I think are the key things (at least in my mind) that we need to discuss/agree on in respect to considering changes to the release process. I don't think these are specific to the model proposed as they could be addressed through different models (including tweaks to what we do today) but are fundamental to agreeing what models might work. I have my opinions/comments on these key issues but will leave that to later as I think its important to tease/out agree on the key decisions first. I think there may be a few more as it is a complex area, but these are the two that I can best identify at this point.

1. Do we do backports or not on LTS and current lines? This is the source of much of the additional steps,
   branches etc. We will already have to do backports for security/critical fixes so the discussion is
   about limiting what we backport such that we can simplify/reduce the day to day work. The flip side is that
   there have been some key areas that we have backported with the goal of speeding adoption (N-API, ESM
   as a few examples) so backporting less may impact some key initiatives. Key point 1: where do we draw
   the line of what is backported.
2. What pace can the ecosystem (end users, module maintainers etc.) consume new Node.js versions with new
   features and breaking changes, particularly if they are not an LTS versions. If we get more/faster feedback
   by making lots of individual versions with breaking changes available that would let the project fix address
   issues sooner but we only get this benefit if the ecosystem has the cycles and desire to adopt/test the new
   versions as they come out. Key point 2: how fast can/will the ecosystem consume non-LTS releases with
   breaking changes

I think that our existing process is based on the opinion at the time in terms of the right balance on those two. If we agree that our opinion has changed since then, that will inform what kind of changes would make sense.

[jasnell]

There appears to be a lack of interest on this so I'll withdraw the proposal.