"Current" should include v12.13

[ljharb]

If Erbium was a semver-minor _{(I still maintain it should have been a 12.12.1 patch, but let's stipulate that it's a minor for the context of this issue)}, then that means it added a feature.

"Current" both conceptually means "latest", and also on the website is described as "latest features" - 12.13 has a feature 12.12 does not, or else it wouldn't have been a semver-minor bump.

In other words, prior to v13.0.0 becoming Current tomorrow, I think that v12.13.0 should be considered Current.

This isn't urgent now - it only happens with every odd .0.0 release - but I think it's important that the release terminology and semver are consistent. When/if v14 goes into LTS, and v15.0.0 is not yet released, I'd expect/hope the latest v14 to be considered Current in the interim.

_{I also think "current" is a way better name than "stable", and although "latest" would be a better name still, I don't think renaming the release line is at all worth the churn it would cause}

[targos]

Technically, v12.13.0 is still the latest release. It is even linked at https://nodejs.org/dist/latest/
Did you open this issue because v12.12.0 is Current on https://nodejs.org/en/ ?

[targos]

In the Node.js release schedule/policy, a release cannot be Current and LTS at the same time, but I agree this can be confusing for people who visit the website between the releases of v12.13.0 and v13.0.0.
I think the best way to fix this would be to remove the Current option from the site if latestLts > latestCurrent.

[ljharb]

Yes, that's why I opened it (also because of ensuing discussion on twitter).

Where does it say in the policy that a release can't be Current and LTS at the same time?

[MylesBorins]

I've opened a PR to fix the landing page for days like today

nodejs/nodejs.org#2707

With this PR Current will not show if it is less than the latest LTS

@ljharb the process regarding branches transitioning is documented in https://github.com/nodejs/release#release-plan

Arguably the language is a bit off as it says When a new odd-numbered major release is cut, the previous even-numbered major version transitions to the Long Term Support plan.... implying the new major being cut triggers the transition... but that isn't the spirit of the program. Current and LTS are two very distinct phases for a branch and in turn define the release process and how we land new changes. All changes landing on an LTS release branch must live in a Current release for at least 2 weeks and as such it is impossible for an LTS release to also be current, it would upend our entire process.

Two actions we can likely do to rectify are

1. Land the PR I opened to remove current from the landing page when days like today occur

• feature: hide current release when LTS release is more recent nodejs.org#2707 landed

2. Modify the language for LTS transition to make it clear that a branch becomes LTS with a SemverMinor release where the LTS bit is set independent of the Current release branch having been cut.

• doc: clarify LTS bit flip process #496

Thoughts?

[apaprocki]

This is also incorrect:

https://github.com/nodejs/node/tree/master#current-and-lts-releases

https://nodejs.org/download/release/

The latest directory is an alias for the latest Current release.

That directory (https://nodejs.org/download/release/latest/) points to 12.13.0, which is not the latest Current release.

[MylesBorins]

@apaprocki would you be open to filing a bug over at nodejs/build about that? That alias is incorrect and should not have been made

[ljharb]

All changes landing on an LTS release branch must live in a Current release for at least 2 weeks and as such it is impossible for an LTS release to also be current, it would upend our entire process.

If this applies to the initial LTS release, then that's already broken, because 12.13 contained things that were not released for 2 weeks.

If it doesn't apply to the initial release, then it doesn't restrict 12.13 from being both LTS and Current, since only further LTS releases need to be Current for 2 weeks.

[apaprocki]

@MylesBorins I think you meant me, not the other user ;) I'll do that.

[MylesBorins]

@ljharb from the same document

Generally changes are expected to live in a Current release for at least 2 weeks before being backported. It is possible for a commit to land earlier at the discretion of the Release working group and the maintainers of the LTS branches.

Only two changes landed in 12.13.0 were new and were landed at the discretion of the LTS team.

[ljharb]

Those are restrictions on what can be LTS - there are no such restrictions on what can be Current. At this point, making 12.13 be Current wouldn't impose any restriction on what can be in the next LTS release.

Is there a technical reason it would be a problem having 12.13.0 be both LTS and Current?

(To reiterate, this isn't urgent - it's fine if Current remains 12.12 this time around, I'm hoping that something can be resolved before v14.0.0 comes out)

[ljharb]

I don’t think that PR closes this issue, unless it requires that current be released before LTS (and even then i don’t think that’s the ideal resolution, just a workable one)

[BridgeAR]

I added it to the release agenda to discuss what we can do to improve the situation / if any release may be LTS and Current at the same time.

AFAIK there are other issues open as well about our terminology and we might want to consolidate these.

[BridgeAR]

@nodejs/releasers this should probably be closed due to #517?

[ljharb]

@BridgeAR #495 (comment) indicated that solving this issue would be a followup to #517, so it’s not resolved yet afaict

[MylesBorins]

@ljharb I don't see anything specific or actionable. I am personally -1 to the idea of having a release be current and LTS at the same time.

Do you have an actionable suggestion to avoid the edge case you are concerned about?

[ljharb]

Could we release v15 before v14 enters LTS? (and going forward, v17 before v16 is LTS, etc) That seems simplest to me.

[BethGriggs]

I was thinking about this when I opened #600

I think we need to determine if it is better to have a short window where we have:

• Multiple current releases (v15.x is released before v14.x becomes LTS)
  • refs: Prevent duplicated "Current Release" #439
• No current release (v14.x becomes LTS first)

I think we end having multiple current releases at times anyway (v13.x was also current when v14.x was released).

Major releases have a tradition of occurring on third Tuesday of April/Oct. I think I'd be okay with the LTS promotion happening a week later than the new major. @nodejs/release thoughts?

[BethGriggs]

Major releases have a tradition of occurring on third Tuesday of April/Oct. I think I'd be okay with the LTS promotion happening a week later than the new major. https://github.com/orgs/nodejs/teams/release thoughts?

Now #726 has landed, we have a policy in place to ensure the promotion to LTS happens after the new major. This mitigates (via intentional timing of the releases) what I recall surfacing the issue.

The issue has been dormant for a while, and I don't believe we intend to make changes to our processes such that a release will be Current and LTS at the same time. With that in mind, I'm going close - but please reopen or comment if there's a further ask or action for us to discuss.