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.

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

LTS support definition #3

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

LTS support definition #3

wants to merge 1 commit into from

Conversation

sheplu
Copy link
Member

@sheplu sheplu commented Feb 29, 2024

First PR to try to standardize how we define LTS and what it means for the Express.js ecosystem, including a first proposal for our releases and support - the value (one year) are a suggestion of my part and are here to be discussed

Inspired from the LTS definition of Fastify

@sheplu sheplu force-pushed the support-version branch 2 times, most recently from 19ab25b to 7506c07 Compare February 29, 2024 23:15
As of the date of this PR (March 1st 2024), the only released and maintained version of Express.js is the v4.
This version was created and published in 2014 and is supporting (working on) all Node.js version between 0.10 and 21.x - with tests run against all of them.

During the conception phase of Express v5 it was discussed to drop the support of all version below Node.js v4 (released in September 2015) - so supporting all versions from Node.js 4.x to Node.js 21.x, representing 18 versions.

Choose a reason for hiding this comment

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

any particular reason to stick with 4.x, if v5 wasn't released yet, and hence dropping versions wouldn't be extra breaking change?

Copy link
Member Author

Choose a reason for hiding this comment

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

this is the point I want to raise, and basically, the best for me would be

  • only support LTS version (18+) but it may be too radical
  • so maybe choose to support v14+

Choose a reason for hiding this comment

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

14+ sounds like a reasonable minimum


## Long Term Support

Express Long Term Support (LTS) version is provided as per defined in this document - and also include all the packages part of the Express.js Organization (express, pillarjs and jshttp).
Copy link
Member

Choose a reason for hiding this comment

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

Just to clarify, all packages will need to start following this and not just express?

Copy link

Choose a reason for hiding this comment

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

All packages would need to provide this as a minimum, I’d assume - but they could certainly support longer if desired, since it’ll probably be cheap for smaller packages to do so.

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 it is really important we clarify this. I think I subtly disagree with @ljharb on this, but so far the docs themselves do not provide enough clarity to have that conversation imo and I think we didn't have that discussion in the other original thread either. I will open an issue in the discussions repo so we can address that. We should block merging this on resolution to that discussion.

Copy link
Member

Choose a reason for hiding this comment

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


Express Long Term Support (LTS) version is provided as per defined in this document - and also include all the packages part of the Express.js Organization (express, pillarjs and jshttp).

1. Express follows a semantic versioning A.B.C (also know as semver), where the major version is represented by "A". Major version are supported for a minimal time of a year (as seen as 365 days).
Copy link
Member

Choose a reason for hiding this comment

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

And this is to say every major version is supported a minimum of 1 year? SGTM. My first reading of this doc was a bit confusing because it made it sound like we'll want to do releases every year, the language in Fastify is a bit clearer and helped me understand the intent of this doc.


1. Express follows a semantic versioning A.B.C (also know as semver), where the major version is represented by "A". Major version are supported for a minimal time of a year (as seen as 365 days).

2. After the time that a LTS version (that can exceed one year) is maintained, the version will move to a maintenance mode during which only security patches will be released. This maintenance mode will be supported for at least one year.
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 the Fastify doc is clearer here too, you're basically saying after a new major version is released, the old one goes into LTS and supported for 1 year?


> In specific case, a version in maintenance mode may require a breaking change to fix a security risk. If this happen, then it will be released as a minor version change but outlined in the release message

3. Major version will be tested against all the LTS versions that were active during the time of the major version. This doesn't mean that the package won't support previous versions, but no tests will be run against them.
Copy link
Member

Choose a reason for hiding this comment

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

Is the LTS here being used to refer to the node.js LTS version and not this doc anymore?


## Express Releases

| Express version | Release | Maintenance | End of Life | Supported Node.js version |
Copy link
Member

Choose a reason for hiding this comment

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

Maintenance seems redundant if I'm reading this doc correctly, anything not the latest version would be in maintenance?

For example, 20 was created in April 2023, moved to LTS in September 2023 and will be in maintenant mode until October 20224 and will run until April 2026.

Express and the ecosystem should follow versions that are not a security risk and keep being updated and patched as a primary support.
It is possible to have some breaking changes between major versions but in the past couple years, it was mostly minimal.
Copy link
Member

Choose a reason for hiding this comment

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

What is this sentence referring to? Express or node.js breaking changes?


### Node.js version supported

As a first point, the Express.js project should only support non-LTS version during their active phase and remove all specific compatibilities when they move out of active status - allowing us to use them as "trial" before the next LTS.
Copy link
Member

Choose a reason for hiding this comment

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

I don't follow this either, what does LTS refer to? Is it saying express should support only new versions during development and not the node.js LTS? What's the trial?

@wesleytodd
Copy link
Member

@ctcpip are we able to update this PR with your proposed changes? Since we merged the website update for the HeroDevs stuff, I would love if we could point folks to a plan here which we have resolved and committed to.

@sheplu
Copy link
Member Author

sheplu commented Sep 1, 2024

@wesleytodd @ctcpip I will spend some time on monday to update it and take into account all previous comments but feel free to ping me directly on slack or just add changes here and I will add them

@kibertoad
Copy link

@sheplu Can I help?

@sheplu
Copy link
Member Author

sheplu commented Sep 1, 2024

@kibertoad of course! can be through issues or we can find some time tomorrow if you prefer :)

@kibertoad
Copy link

kibertoad commented Sep 1, 2024

@sheplu Async via issues would be easier, I reckon

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants