Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Express LTS strategy #199

Merged
merged 10 commits into from
Feb 29, 2024
Merged

Express LTS strategy #199

Changes from 1 commit
Commits
Show all changes
10 commits
Select commit Hold shift + click to select a range
bf4133f
first draft
Feb 26, 2024
9b928ab
Update docs/LTS-strategy.md
kibertoad Feb 27, 2024
a9c3299
Update docs/LTS-strategy.md
kibertoad Feb 27, 2024
6c17050
Update docs/LTS-strategy.md
kibertoad Feb 27, 2024
06bf8eb
Update docs/LTS-strategy.md
kibertoad Feb 27, 2024
cdb1090
Update docs/LTS-strategy.md
kibertoad Feb 27, 2024
b0cb097
Improve wording
Feb 28, 2024
39cff08
Update docs/LTS-strategy.md
kibertoad Feb 28, 2024
b38d3f3
Add clarity on regular semver major cadence
Feb 28, 2024
00f261b
Merge remote-tracking branch 'origin/feat/lts-strategy' into feat/lts…
Feb 28, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
38 changes: 38 additions & 0 deletions docs/LTS-strategy.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,38 @@
# Express LTS Strategy

## Goals

* Maintain strict Node.js version support within a single Express major release.
* Provide good ergonomics and developer experience for Express maintainers
* Provide good experience for users who want to keep their Express projects that up-to-date
* Avoid stagnation and blocking innovation that is good for the end users
wesleytodd marked this conversation as resolved.
Show resolved Hide resolved

## 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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Love this section, especially this line! 🎉

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1 this is a great way to explain it

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

* Provide timed cadence of Node.js version support dismissal

### Rationale behind dropping support for old Node.js versions

* Avoid blocking Node.js core from making progress and removing deprecated parts of the codebase
* Avoid getting outdated bug reports or security issues
* Keep options for adopting newer patterns and tooling open
kibertoad marked this conversation as resolved.
Show resolved Hide resolved

### Rationale behind conservative policy of breaking changes

* 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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thanks!


* 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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is great, thanks for capturing it

* Version support removal must come with clear benefits for one of the three - Express users, Express maintainers or the Node.js core project. Version support is not dropped on a merely time-based basis.
kibertoad marked this conversation as resolved.
Show resolved Hide resolved
* Any discontinuation of a Node.js version support is always a semver major release.

### Active branches

* Several semver major branches can be maintained at the same time, in case there is a significant userbase for older semver major releases.
kibertoad marked this conversation as resolved.
Show resolved Hide resolved
* No features are backported to older semver major branches
wesleytodd marked this conversation as resolved.
Show resolved Hide resolved
* Critical bugfixes may be backported to older semver major branches
kibertoad marked this conversation as resolved.
Show resolved Hide resolved
* High-impact security fixes are very likely to be backported to older semver major branches
kibertoad marked this conversation as resolved.
Show resolved Hide resolved