Define Policy regarding Semver-Minor LTS Releases

[MylesBorins]

Currently we have been not particularly exact about when we do Semver-Minor releases on LTS branches. The only real guideline has been "not too often". My impression was that we wanted to space out Semver-Minor releases to avoid LTS feeling like it was moving too fast (which seems fairly reasonable to me).

We have found ourselves in a position where a change has landed into Core, and soon in a Current Release, that solves an edge cases for users behind firewalls and needing to use proxies

nodejs/node#9139

We could likely do a Semver-Minor release of Boron but having just cut a minor of Argon I was hesitant to follow up with yet another minor.

There are also practical reasons for holding off on another minor release, particularly waiting for a bit more of a backlog.

I'd like to hear people's opinions regarding Semver-Minor changes.

[mhdawson]

With our planned monthly release cadence, waiting means that it could take up two 2 months to get a semver-minor change into a release.

In general I think batching them up makes sense, but if we have something people are asking for, I'd lean towards not waiting provided the risk of the change is low, and specifically call out that it normally would have waited, but due to customer need we are putting it would without waiting for a larger batch. I'd still wait for the next planned release, and the required 2 weeks settling in current, but that would be at most 1 month out.

For the specific case on nodejs/node#9139 it does sound like we have at least 2 people asking for it.

[sam-github]

I think the history of the LTS releases shows they have been kept very stable. I'd be OK with a montly release that was minor or patch depending on the what had been release in Current for 2 weeks - acknowledging that the LTS WG can always release more frequently, or hold features/patches back, when it deems it important for ecosystem stability.

Fwiw, as a user of LTS releases, I'd never noticed they were alternating patch/minor.

[sam-github]

https://github.com/nodejs/LTS#lts-plan says minors have to be proposed, cf. nodejs/node#7696 (comment), but what is the criteria for considering? Am I hijacking this issue, or is that relevant here? :-)

[MylesBorins]

The primary consideration is that it has a genuine benefit to the platform and has no chance of breaking anything. Each one is individually brought up to the LTS wg and voted on

[gibfahn]

@MylesBorins I guess the problem with that would be that if the person who raises the PR isn't familiar with the backport process, then they won't know to propose the backport.

has no chance of breaking anything

s/no/a low/ ?

[MylesBorins]

@gibfahn that's why I've in the past audited semver-minors. Nothing stopping anyone from doing it
¯\_(ツ)_/¯

edit: s/no/very low :p

[mhdawson]

I'd characterize is more of a risk/reward than a fixed level for chance of breaking things. If the benefit of the change is low then it better have a very low chance of breaking things to be considered. If its really important like a security issue we'll accept more risk of breakage.

[MylesBorins]

I think I'm happy with how we currently do this. Closing for now