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
When a new odd-numbered major release is cut, the previous even-numbered major version transitions to the Long Term Support plan.
I would like to question why coinciding the two releases on the same day is necessary. Note that while the policy doesn't mention 'same day' explicitly, this is how we have chosen to interpret this statement in the project.
In practice this means that:
The release team, the CI, and the project overall has to manage two releases concurrently. This puts extra burden on resources, processes, and most importantly, people.
At the time the even-numbered branch is ready to transition to LTS, there is no Current stream. This means that any changes have be landed directly onto the to-be-LTS release (e.g. see [v8.x] https: revert "refactor to use http internals" node#16660). This means that we don't get the benefit of getting feedback from the ecosystem from the current branch, and potentially breaking changes can land into the LTS release.
I would like to propose that we try to separate the releases. It would have made sense to release 9.0.0 two weeks prior to 8.9.0 in the current example.
Our policy states:
I would like to question why coinciding the two releases on the same day is necessary. Note that while the policy doesn't mention 'same day' explicitly, this is how we have chosen to interpret this statement in the project.
In practice this means that:
I would like to propose that we try to separate the releases. It would have made sense to release
9.0.0two weeks prior to8.9.0in the current example.