Clarify what happens with odd-numbered releases in April

[addaleax]

Write down my understanding of the process for odd-numbered releases once they transition into Maintenance mode.

[mhdawson]

LGTM

[Fishrock123]

cc @nodejs/lts ... pretty much what I've been saying for a long time

[jasnell]

I'm not sure Maintenance is the right label. Odd numbered releases are never covered by the LTS plan.

[Fishrock123]

It has the identical effect. I am quite sure it is indeed the correct label. We still do not call it LTS.

[jasnell]

I disagree. Calling it Maintenance and linking it to the LTS plan brings along certain assurances that things like security updates and critical bug fixes would be actively addressed by the LTS WG, which they are not in odd numbered releases. Sure, some subset of collaborators could choose to continue providing such updates during the 3 month period, but that doesn't mean there's any obligation on the part core to do so. The LTS Maintenance phase carries that kind of guarantee for branches that actually are under the LTS program.

[MylesBorins]

I have mixed feelings on this as well. Perhaps we can call it a EOL window or something of that nature. It isn't exactly the same as maintenance mode, and as @jasnell says I think it is a good idea to not conflate them

[Fishrock123]

Calling it Maintenance and linking it to the LTS plan brings along certain assurances that things like security updates and critical bug fixes would be actively addressed by the LTS WG

Exactly.

which they are not in odd numbered releases.

I think this is false. We are explicitly guaranteeing this for these 2? 3? months.

[addaleax]

(Btw, I filed this PR because it came up in conversation with @othiym23 that this isn’t really written down anywhere and the image on the LTS WG page was basically the best we have to offer when it comes to the lifetime of odd-numbered release lines. I don’t really care if this PR gets landed here or anything but whatever the policy is should still be communicated somehow.)

[jasnell]

@Fishrock123 ... for as long as we've been talking about the LTS plan, the odd-numbered releases have never been considered to be covered. The idea has always been that only the even-numbered releases are covered. This idea has been expressed in every communication we've had around the LTS policy. Any odd-numbered major that is not the Current major should simply not have any label or assurances of continued support. If individual collaborators want to continue supporting those for a few months, then awesome, but that doesn't mean it should automatically have the same guarantees as an actual LTS branch.

[Fishrock123]

Right! That's why we don't refer to them as LTS. Only Maintenance!

[jasnell]

@addaleax ... the wording I would recommend is this:

Odd-numbered major releases are not covered in any way by the LTS plan. However,
after a new even-numbered major release is cut in April, the prior odd-numbered
release *may* be continued to be supported by interested collaborators for up to
3 months.

[addaleax]

@jasnell I’m happy to use your wording for this PR, but I’m pretty sure I remember an actual discussion about the lifetime of non-LTS release lines happening (unfortunately, not sure where that happened, but it was in the context of v5), and that the result was what @Fishrock123 said (3 months of support).

[jasnell]

Yes, the CTC discussed supporting for up to three months but that's separate from LTS maintenance.

[rvagg]

I don't have a reference but this has come up a few times in meetings and the last time we discussed it we agreed on 2 months. I reflected this in my README rewrite in #121 (I explicitly noted this in the comment for that PR).

[Fishrock123]

I think we discussed up to 3 but settled on 2. We did 2 months for v5.

[rvagg]

One of the primary reasons we did 2, fwiw, is from the experience of v5—some of us imagined that it'd still be busily updated from master but it turned out that nobody really cared to update it so we only threw critical updates at it and were all pretty happy when it stopped being supported.

[Ajedi32]

FWIW, I too found the lack of information on this to be rather confusing. The README should definitely include some sort of explanation on how non-LTS releases are handled after a new "Current" LTS branch is cut. The chart in the README currently seems to imply that there can be multiple "Current" branches going at any given time.

[mhdawson]

We should either revive this discussion or close the PR. How about we update to say:

"An odd-numbered major release will cease to be actively updated
when the subsequent even-numbered major release is cut. Updates will be limited to
critical updates for a period of 2 months, from April until May."

@addaleax, @jasnell @rvagg @MylesBorins @Fishrock123

[gibfahn]

Adding this to the lts-agenda as we really should make a decision one way or the other.

[mhdawson]

From discussion in the LTS meeting the suggestion is:

"An odd-numbered major release will cease to be actively updated
when the subsequent even-numbered major release is cut."

[mhdawson]

@addaleax do you want to make this update or have one of us at the meeting do that ?

[jasnell]

Hmmm... that's not entirely true. We've said consistently that the odd numbered majors would continue to be supported until June (2 months after the subsequent even-numbered major is cut). While there wouldn't be any plans to cut new releases, if a critical security issue came up, I have no doubt that we'd patch it within that time frame.

[mhdawson]

@jasnell that was part of the discussion we had. However we landed on a statement that just says we won't actively update. Nothing in that wording says we can't do a new release if we felt is was appropriate. Specifically there was discussion around not wanting to specify a timeframe.

[jasnell]

Ok

[gibfahn]

@hbetts @kgryte If you don't agree with (or are confused by) this could you comment here so we can discuss it?

[hutson]

@gibfahn thank you for reaching out. I've been following, though perhaps not successfully, this discussion, and though I don't remember the specifics of why I was confused about that statement, perhaps I can walk my way there by responding to a few comments in the thread.

Calling it Maintenance and linking it to the LTS plan brings along certain assurances that things like security updates and critical bug fixes would be actively addressed by the LTS WG

Without further context, seeing the pull request paragraph on this project's README would, to me, imply that LTS is actively managing the maintenance period of an odd-numbered release.

I don’t really care if this PR gets landed here or anything but whatever the policy is should still be communicated somehow.

@addaleax, I really appreciate your efforts to further document, and where helpful, add context, to policies, practices, and in this case, a diagram.

I feel that for many there's probably little need for a deeper grasp of the intricacies of how a maintenance period is managed. For myself, where I fulfill the role as one of the definers of my company's Node usage policy, the details can really help in the development of that policy.

If individual collaborators want to continue supporting those for a few months, then awesome, but that doesn't mean it should automatically have the same guarantees as an actual LTS branch.

I assume when the label maintenance appears in official Node documentation, that there is an officially recognized body of developers that have voluntarily taken on the burden of providing maintenance in some capacity. However, in the case of the maintenance window for an odd-number major, that's not really the case. So documenting the maintenance window gives at least me, the wrong impression.

I think we discussed up to 3 but settled on 2. We did 2 months for v5.

^ Is there not a document, similar to the LTS README, that defines whether it's 2 months or 3 months?

Specifically there was discussion around not wanting to specify a timeframe.

@gibfahn, okay, so I'm not sure confusion was exactly what I was going for.

I like the concise language of the revised statement as posted by @mhdawson.

My concern is that the language, along with the discussion here, opens the door for requests to back-port changes into an odd-numbered major version far after an even-numbered major version. Though LTS does not directly provide that support, LTS may get distracted by such requests (in theory, though I have the feeling that doesn't actually happen much in practice).

[gibfahn]

I assume when the label maintenance appears in official Node documentation, that there is an officially recognized body of developers that have voluntarily taken on the burden of providing maintenance in some capacity.

I think the only definition of maintenance we have is the one in the README:

Once a release moves into Maintenance mode, only critical bugs, 
critical security fixes, and documentation updates will be permitted.

Basically maintenance means we still maintain the ability to do releases, but we don't do regular updates, and we'd only consider a release if node was broken for a large number of people.

Without further context, seeing the pull request paragraph on this project's README would, to me, imply that LTS is actively managing the maintenance period of an odd-numbered release.
^ Is there not a document, similar to the LTS README, that defines whether it's 2 months or 3 months?

There is not currently a document that defines the maintenance period of an odd-numbered release. That's what this PR is trying to clarify.

My concern is that the language, along with the discussion here, opens the door for requests to back-port changes into an odd-numbered major version far after an even-numbered major version.

Interesting that you had that feeling. From my point of view this is the least commitment we could make. Given the question of "how long should the maintenance period of an odd-numbered release be", we went with "0 months".

The reality is that someone can always ask that we backport a change to an EoL release, it's just that the answer will be no 99.99% of the time. The only time I could imagine us doing it is if (for example) Node 8 came out and broke a huge proportion of Node 7 code, and then there was a critical security vulnerability in Node 7 a week or two after it went EoL...

Though LTS does not directly provide that support, LTS may get distracted by such requests (in theory, though I have the feeling that doesn't actually happen much in practice).

You're right, this might be an issue down the line, but I don't think we need to worry about it right now, if it becomes a problem we can just update the docs.

---

@gibfahn, okay, so I'm not sure confusion was exactly what I was going for.

I usually take 😕 to mean anything more complex than 👍 or 👎 , there isn't exactly a huge range to choose from 😁 .

[addaleax]

@mhdawson If that’s the resolution, I’d suggest one of you takes over and makes that change.

[gibfahn]

I’d suggest one of you takes over and makes that change.

#220