The Node.js release process is designed to support both stability and experimentation. It allows us to both support our ecosystem with a stable platform while still inspiring a bit of mad science to move the platform forward.
TLDR;
- Current is more experimental than LTS
- Odd Numbered Current releases are treated as more experimental than Even Numbered releases
- Any change in a Current release is subject to being reverted if it is disruptive
- The reversion process can take a bit longer than desired due to the fact that quorum needs to be reached
- We are working on improving this
- No change will make it's way to LTS that hasn't lived in Current for an extended period of time
The majority of new PR's are directly targetting against. Changes are then moved to our various release lines based on our release process.
There are two primary release lines, Long Term Support (LTS) and Current.
The purpose of the Current release line is to get all non semver-major breaking changes out into the wild as soon as possible to ensure there are no unexpected breakages or behavior changes. These releases can happen as often as weekly if there is enough content. Things that land in Current can be reverted and there are many instances where this has happened. A new Current release is cut directly from master every 6 months. In general we have treated Odd Numbered Current releases as more experimental, and as an opportuntiy to test out changes that have a potential to be reverted.
The purpose of LTS is to offer a hardened and stable release line that individuals can trust to not change behavior or break. Currently this includes v4 and v6. All LTS release lines will spend 6 months as a current release before transitioning to LTS. Once it has transitioned to LTS changes must live in a Current release for at least 2 weeks without a regression before they make their way into this release line. The majority of changes that are added to an LTS release are semver-patch, although semver-minor changes can be included if voted on by the LTS WG.
Note: It dawns on me that perhaps one thing missing from this is a process for announcing to the community what semver-major changes are coming down the pipeline in the next Current release, please comment on ways you think this could be improved.
Missing examples on this. What is non-semver breakage, what is? - concrete (past) examples is better than hypotheticals I reckon
Also yeah the whole odd vs non-odd version thing is super confusing from people on the outside rn; multiple core people are saying different things - having the story straight would be cool