feat(ADR): LTS Strategy #352
Conversation
wesleytodd
force-pushed
the
adr-lts-strat
branch
from
06db355 to
7ace9f9
Compare
| at the time of release and maintain that support through its entire life cycle. This includes EOL Node.js versions. | ||
| - `express` may choose to continue support for EOL Node.js versions in all three phases if deemed valuable, but will | ||
| strive to cut support before it becomes a drain on progress. | ||
| - All `express` dependency packages must support, at a minimum, the Node.js versions that are supported by the `express` |
There was a problem hiding this comment.
The combination of this and preceding line might mean that when an unsupported version of node.js has a particular vulnerability, dependency packages are forced to provide workarounds to avoid exposing the vulnerability.
There was a problem hiding this comment.
Hm, interesting, yeah I think I follow but I also think that we have discussed something similar to this as well before. Our discussion was around v4 users stuck on EOL node versions and how our pass through apis expose many of the same vulns as the underling runtime. IIRC we decided this was out of scope for what we consider this projects problem to solve.
Now that you are saying that though, I wonder if we should add this to our threat model doc? https://github.com/expressjs/security-wg/blob/main/docs/ThreatModel.md cc @expressjs/security-wg
There was a problem hiding this comment.
I think it's ok to go the other way and explicitly say that express and it's ecosystem will not be forced to work around vulns in EOL Node.
There was a problem hiding this comment.
We briefly discussed today, and we have agreed to remove some of this language from this doc, to keep it focused specifically on release strategy and to remove excess details that do not need to be explicitly stated or promised.
docs/adr/lts-strategy.md
Outdated
|
|
||
| | Major | CURRENT | ACTIVE | MAINTENANCE | EOL | | ||
| | ----- | ------- | ------ | ----------- | --- | | ||
| | 4.x | | | 2025-04-01 | 2026-10-01 or later | |
There was a problem hiding this comment.
When v5 becomes tagged as latest, users running npm i express need to be aware they are using v5 and must know that should not use v4 which will be EOL after a certain date. The reason is that it will invalidate a lot of tutorials and beginner content, so it must be clear to users that they are installing v5 and v4 will not be supported.
Id start preparing the ecosystem for the end of v4 by adding deprecation warnings, blogposts etc...
There was a problem hiding this comment.
I am going to write the blog post after following up on these reviews. I am not sure we will even deprecate on npm after that. That said, I agree for beginners this is not enough and we might want to do more. I agree this is going to be a big problem and it is one why we didn't go latest earlier. Do you think we should do a postinstall message or something? This is for sure a tough one to solve, so open to any recommendations.
There was a problem hiding this comment.
yeah I think we should add a warning (not sure you can do it through postinstall since you cant write to stdout for sure) saying hey express 4 will be EOL this date, please migrate
There was a problem hiding this comment.
You could certainly npm deprecate every v4 version except the latest one, though.
There was a problem hiding this comment.
We had discussed that at one point IIRC and I think we were unsure of the value, but since we won't be doing that for sure until EOL, we have 18 months to decide.
There was a problem hiding this comment.
The value would be to aggressively push people, at the least, to be on the latest v4, and at best, v5.
There was a problem hiding this comment.
We discussed briefly today, but this is somewhat out of scope for what we are trying to do with this document. Let's create a separate issue to track strategy around v4 EOL planning.
Co-authored-by: Zbyszek Tenerowicz <[email protected]>
Co-authored-by: Zbyszek Tenerowicz <[email protected]>
| deprecation notices. | ||
| - Users are recommended to use `CURRENT` lines and to upgrade as quickly as their risk profile allows | ||
|
|
||
| #### ACTIVE |
There was a problem hiding this comment.
Question from @naugtur on bluesky I didn't want to loose:
One question I have after reading is - what about breaking changes in the current or active phase? If they're forced by a security issue and the breakage is not limited to insecure use, how would it be indicated in the version number and what other things would happen?
There was a problem hiding this comment.
I don't think we benefit from specifying anything particular here, because if we ever had a potential non-semver breaking change, it would be evaluated very carefully, and only done if the benefit truly outweighed the harm it would cause.
docs/adr/lts-strategy.md
Outdated
|
|
||
| | Major | CURRENT | ACTIVE | MAINTENANCE | EOL | | ||
| | ----- | ------- | ------ | ----------- | --- | | ||
| | 4.x | | | 2025-04-01 | 2026-10-01 or later | |
There was a problem hiding this comment.
| | 4.x | | | 2025-04-01 | 2026-10-01 or later | | |
| | 4.x | | | 2025-04-01 | 2026-10-01 | |
We can always "negociate" but let's avoid setting expectation to delay that day forever :)
There was a problem hiding this comment.
There was a problem hiding this comment.
If we are setting a date, we should have reasonable confidence that we would actually meet that date. Otherwise, it's just completely arbitrary. I suggest we leave as is, or put TBD.
|
I had dropped this draft of messaging around EOL into the TC meeting issue |
A proposal for an LTS strategy with committed dates and next steps. Please see the goals/non-goals for this ADR.
I attempted to copy/paste without edits from all the sources we had. I admit there was a lot of it and so if I missed something please help and link to it so I can get it included.