You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Node.js creates new version every years, with a LTS being stable for ~3 years. 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.
If other version keep to work with that, then this is a good bonus but we should not maintain a compatibility for all Node.js version.
For example
latest Springboot release only work with Java 17 and above: released in 2021
latest Symfony release only work with PHP8.1 and above: released in 2021
Laravel is almost the same as Symfony
Most of the framework seems to only be compatible with version of the runtime (or language) released ~3 years ago, so something between v14 and v16
Expectation
Define a clear list of supported version, and a process to deprecate a support of a previous version. This way users will be able to know when we will drop the support of a Node.js version.
By keeping less supported version, it may also improve some performance and lowering the quantity of code part of packages - code used to handle the variation and breaking changes.
Implementation
Update Technical Priorities with that information (or create the document)
Work on updating all repositories to be tested only against chosen versions
Note: As Express@5 was announced supporting a specific set of version (reducing the number already), this topic would mostly be for Express@6
Status
Part: Organization
Status:
Draft
Even if the choice to support specific Node.js versions is mostly technical, it can also be a huge organizational decision as this would mostly impact how the project operates.
Express relies on Node.js as the runtime and is then bound to security by Node.js versions. The Node.js project is keeping two versions “maintained” and one current at the same time and we should thrive to officially support only them
One maintenance version (currently v18)
One LTS version (currently v20)
The future LTS version (called “current”)
The text was updated successfully, but these errors were encountered:
Motivation
Node.js creates new version every years, with a LTS being stable for ~3 years. 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.
If other version keep to work with that, then this is a good bonus but we should not maintain a compatibility for all Node.js version.
For example
Most of the framework seems to only be compatible with version of the runtime (or language) released ~3 years ago, so something between v14 and v16
Expectation
Define a clear list of supported version, and a process to deprecate a support of a previous version. This way users will be able to know when we will drop the support of a Node.js version.
By keeping less supported version, it may also improve some performance and lowering the quantity of code part of packages - code used to handle the variation and breaking changes.
Implementation
Update Technical Priorities with that information (or create the document)
Work on updating all repositories to be tested only against chosen versions
Note: As Express@5 was announced supporting a specific set of version (reducing the number already), this topic would mostly be for Express@6
Status
Part: Organization
Status:
Draft
The text was updated successfully, but these errors were encountered: