Skip to content

Instantly share code, notes, and snippets.

@MylesBorins
Last active November 9, 2016 05:24
Show Gist options
  • Save MylesBorins/a3a0ebd76d166ce6b5c9f3a0683d19ae to your computer and use it in GitHub Desktop.
Save MylesBorins/a3a0ebd76d166ce6b5c9f3a0683d19ae to your computer and use it in GitHub Desktop.
Node.js Process: Stability and Mad Science

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.

@MylesBorins
Copy link
Author

It is worth noting that this is a high level overview of our current process, please feel free to comment on way in which we can improve the above. We can than take those proposed changes to the CTC / TSC and try and get buy in from the project

@Fishrock123
Copy link

Odd Numbered Current releases are treated as more experimental than Even Numbered releases

This is not currently true so that would be a policy change.

Also I'm severely against this because I'm bloody sick of the meme that nothing has changed with our release process because LITERALLY EVERYTHING HAS.

/me is unhappy about this

@Fishrock123
Copy link

There are two primary release lines, Long Term Support (LTS) and Current.

Messaging is incorrect. We refer to release lines by numbers. This is the... I'm going to call it "support mode". (LTS Mode)

@yoshuawuyts
Copy link

non semver-major breaking changes

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

@yoshuawuyts
Copy link

Also feel these docs describe a lot of process, not a lot of what should and shouldn't - getting behind a philosophy is easier than getting behind a process

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment