Express LTS strategy #199

kibertoad · 2024-02-26T23:57:33Z

wesleytodd

This is AWESOME. Thanks for getting this started. I made some comments to seed conversation, and I think we might want to expand a bit more on some of them, but generally I think this is an awesome start.

docs/LTS-strategy.md

wesleytodd · 2024-02-27T00:17:56Z

docs/LTS-strategy.md

+## Non-Goals
+
+* Only support the active LTS releases of Node.js
+* Support the widest possible set of Node.js versions. We aim to maintain a healthy balance between backwards compatibility and toolchain modernization.


Love this section, especially this line! 🎉

I'm not actually sure this makes sense - a healthy balance imo is the same thing as "widest possible set". If a node version prevents using modern toolchains, for example, then that's not a version that'd be included in that set.

@ljharb I'll think about possible wording improvements here, but the intent is to emphasize that we only want to support a set of versions that do not contradict the rest of the goals defined. This is very important to make explicit in the context of Express specifically, as it has a long-standing tradition of preserving the compatibility to the detriment of everything else.

+1 this is a great way to explain it

I don’t think any of the detriments you refer to have anything to do with refusing to drop compat for node, but with other things - but i look forward to an alternative phrasing.

a healthy balance imo is the same thing as "widest possible set"

As other said, I disagree with the wording but maybe your meaning hinges on the definition we use for "possible"?

Like if we said "we want to ship diagnostic channels so it is not possible to support versions before them" (I am trying to make a hypnotically based on a reality from the past pillarjs/router#96) does that fit your definition? We would drop the old node versions which dont support it in the next major so we could ship support without a lot of compatibility code.

Yes, of course it fits my definition. If we need a feature that requires dropping a version, then that version is no longer possible to support.

I also especially like the implied path of "ship support with compat code, and then drop the compat code and the node versions that need it in the next major" - that's a very user-friendly way to do a major bump.

docs/LTS-strategy.md

wesleytodd · 2024-02-27T00:19:44Z

docs/LTS-strategy.md

+* Minimize disruption for end users
+* Be mindful of the fact that some users are still running obsolete versions of Node in production
+
+### Guidelines for dropping support of Node.js versions


I think this is the section I want us to discuss more deeply. Ideally we also put together a calendar view like Node does to see in comparison to Node majors how express majors would line up.

Yeah! Having a calendar is one of the best ways to explain the rules for the end users, but currently is very solid 🙂

I think we should make a diagram like node has, maybe even overlay our support over the existing node support schedules?

sure, but let's address this in a separate PR

@wesleytodd @UlisesGascon I think @ljharb strongly objected to having a timed deprecation without a practical justification. We need to have this established unambiguously within the strategy. Do we or not do time schedule-based Node version deprecation?

Either way, but it seems easy enough to do it before merging ¯\_(ツ)_/¯

@kibertoad if you get to it, awesome. If not, lets try and merge this before EOD so we can start those other PRs to clarify and expand.

addressed. unless there are major outstanding objections to some of the wording, I would suggest merging it as-is and iterate in follow-up PRs.

@wesleytodd Can I get push permissions for the repo?

I agree and will merge now. I will also really quickly setup a committer team for this repo and add you.

docs/LTS-strategy.md

ljharb

Thanks for writing this up!

ljharb · 2024-02-27T00:45:24Z

docs/LTS-strategy.md

+## Non-Goals
+
+* Only support the active LTS releases of Node.js
+* Support the widest possible set of Node.js versions. We aim to maintain a healthy balance between backwards compatibility and toolchain modernization.


I'm not actually sure this makes sense - a healthy balance imo is the same thing as "widest possible set". If a node version prevents using modern toolchains, for example, then that's not a version that'd be included in that set.

ljharb · 2024-02-27T00:46:04Z

docs/LTS-strategy.md

+
+### Guidelines for dropping support of Node.js versions
+
+* In order to smoothen the experience of users updating to a new semver major Express version, Express should always support at least one even numbered Node.js version above the current lowest supported one before the drop can be considered. For example, if the lowest supported version is 20, Express support for Node 20 cannot be dropped until Express supports at least Node 22. This ensures that Express updates can be done independently from the Node.js version update.


this is great, thanks for capturing it

docs/LTS-strategy.md

Co-authored-by: Wes Todd <wes@wesleytodd.com>

Co-authored-by: Jordan Harband <ljharb@gmail.com>

Co-authored-by: Wes Todd <wes@wesleytodd.com>

UlisesGascon

Fantastic proposal @kibertoad! Thanks for doing this.

IMO this is great and I feel confident with the current state (previous discussed comments aside). I assume that might do more tweaks in the future (but not a blocker for this PR), specially when we will include the release schedule (calendar) as we will need to fit this ideas more intro a concrete schematics 👍

UlisesGascon · 2024-02-27T11:08:25Z

docs/LTS-strategy.md

+* Minimize disruption for end users
+* Be mindful of the fact that some users are still running obsolete versions of Node in production
+
+### Guidelines for dropping support of Node.js versions


Yeah! Having a calendar is one of the best ways to explain the rules for the end users, but currently is very solid 🙂

UlisesGascon · 2024-02-27T11:08:31Z

docs/LTS-strategy.md

+## Non-Goals
+
+* Only support the active LTS releases of Node.js
+* Support the widest possible set of Node.js versions. We aim to maintain a healthy balance between backwards compatibility and toolchain modernization.


+1 this is a great way to explain it

docs/LTS-strategy.md

wesleytodd · 2024-02-27T19:14:58Z

Here is an example we can also reference. https://github.com/debug-js/debug/releases?page=2

Debug, a direct dep, dropped node versions which blocked us updating.

docs/LTS-strategy.md

Co-authored-by: Jordan Harband <ljharb@gmail.com>

ljharb

LGTM! thanks for iterating

kibertoad · 2024-02-28T00:44:37Z

OK, I think this might be ready to be merged as a first version, but of course we should keep iterating over it.

Should we open the discussion of what toolchain to use as a next step? This would help inform the decision of which particular versions to support in the first upcoming semver major release

wesleytodd · 2024-02-28T15:46:08Z

docs/LTS-strategy.md

+* Minimize disruption for end users
+* Be mindful of the fact that some users are still running obsolete versions of Node in production
+
+### Guidelines for dropping support of Node.js versions


Can we merge without a consensus on this? I am leaning yes? And then we can open targeted PRs to update these and discuss after?

…-strategy # Conflicts: # docs/LTS-strategy.md

first draft

bf4133f

kibertoad mentioned this pull request Feb 26, 2024

EFI: Express LTS Strategy #196

Open

wesleytodd requested changes Feb 27, 2024

View reviewed changes

ljharb reviewed Feb 27, 2024

View reviewed changes

kibertoad and others added 5 commits February 27, 2024 08:16

Update docs/LTS-strategy.md

9b928ab

Co-authored-by: Wes Todd <wes@wesleytodd.com>

Update docs/LTS-strategy.md

a9c3299

Co-authored-by: Wes Todd <wes@wesleytodd.com>

Update docs/LTS-strategy.md

6c17050

Co-authored-by: Wes Todd <wes@wesleytodd.com>

Update docs/LTS-strategy.md

06bf8eb

Co-authored-by: Jordan Harband <ljharb@gmail.com>

Update docs/LTS-strategy.md

cdb1090

Co-authored-by: Wes Todd <wes@wesleytodd.com>

UlisesGascon approved these changes Feb 27, 2024

View reviewed changes

Improve wording

b0cb097

kibertoad commented Feb 28, 2024

View reviewed changes

docs/LTS-strategy.md Outdated Show resolved Hide resolved

Update docs/LTS-strategy.md

39cff08

Co-authored-by: Jordan Harband <ljharb@gmail.com>

kibertoad marked this pull request as ready for review February 28, 2024 00:42

kibertoad requested a review from wesleytodd February 28, 2024 00:42

ljharb reviewed Feb 28, 2024

View reviewed changes

wesleytodd approved these changes Feb 28, 2024

View reviewed changes

Igor Savin added 2 commits February 29, 2024 00:58

Add clarity on regular semver major cadence

b38d3f3

Merge remote-tracking branch 'origin/feat/lts-strategy' into feat/lts…

00f261b

…-strategy # Conflicts: # docs/LTS-strategy.md

wesleytodd merged commit 664d949 into expressjs:master Feb 29, 2024

kibertoad deleted the feat/lts-strategy branch February 29, 2024 00:15

wesleytodd mentioned this pull request Apr 17, 2024

Clarification Needed: Minimum Node.js Version for CI GitHub Action #229

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Express LTS strategy #199

Express LTS strategy #199

kibertoad commented Feb 26, 2024

wesleytodd left a comment

wesleytodd Feb 27, 2024

ljharb Feb 27, 2024

kibertoad Feb 27, 2024

UlisesGascon Feb 27, 2024

ljharb Feb 27, 2024

wesleytodd Feb 27, 2024

ljharb Feb 27, 2024

wesleytodd Feb 27, 2024

UlisesGascon Feb 27, 2024

wesleytodd Feb 27, 2024

kibertoad Feb 28, 2024

kibertoad Feb 28, 2024

ljharb Feb 28, 2024

wesleytodd Feb 28, 2024

kibertoad Feb 28, 2024

wesleytodd Feb 29, 2024

kibertoad Feb 29, 2024

ljharb left a comment

ljharb Feb 27, 2024

ljharb Feb 27, 2024

UlisesGascon left a comment

UlisesGascon Feb 27, 2024

UlisesGascon Feb 27, 2024

wesleytodd commented Feb 27, 2024

ljharb left a comment

kibertoad commented Feb 28, 2024

wesleytodd Feb 28, 2024


		### Guidelines for dropping support of Node.js versions

		* In order to smoothen the experience of users updating to a new semver major Express version, Express should always support at least one even numbered Node.js version above the current lowest supported one before the drop can be considered. For example, if the lowest supported version is 20, Express support for Node 20 cannot be dropped until Express supports at least Node 22. This ensures that Express updates can be done independently from the Node.js version update.

Express LTS strategy #199

Express LTS strategy #199

Conversation

kibertoad commented Feb 26, 2024

wesleytodd left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ljharb left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

UlisesGascon left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

wesleytodd commented Feb 27, 2024

ljharb left a comment

Choose a reason for hiding this comment

kibertoad commented Feb 28, 2024

Choose a reason for hiding this comment