Node.js versions:
How do they work?
With your host Myles Borins
@thealphanerd
View Source 2016
Hallo!
My Name is Myles
I currently work at a small disruptive startup called IBM
contributing to Node.js
The opinions expressed in this talk are solely my own
Versions, how do they work?
Versions, are a lot like magnets
Stick with me on this
Versions, are a lot like magnets...
Many people are pretty darn confused about how they work
#REALTALK
this stuff is complicated
you do not need to understand everything
to contribute in a meaningful way
starting from a small piece
let's see how it becomes something bigger
What is semver?
check out http://semver.org/
What is a Patch
What is a Minor
What is a Major?
Current:
v6.5.0
Active LTS:
v4.5.0
Maintenance LTS:
v0.10.46 & v0.12.15
Some History of
where the heck v1 - v3 went
and what the deal is with v0.12
Node started with alternating releases
Even was stable
Odd was unstable
It was taking a long time
for v0.12.0
Let alone v1.0.0
The project was forked in Dec of 2014
Released as v1.0.0
v0.12.0 Released
Feb 2015
Just before Node Summit
v1 - v3 were all part of the iojs project
Node was put into a foundation
The projects merged as v4.0.0
September of 2015
What is Current?
What is Active LTS?
What is Maintenance LTS?
What about Master?
What happened to Stable?
So how the heck do we manage all of this?
Magic
Git Magic
We maintain release branches
v0.10.x v0.12.x v4.x v5.x and v6.x
When we are ready for a current release
We branch off of v6.x
And cherry pick commits from Master
We maintain staging branches for LTS
v4.x-staging
Used to stage changes as they are audited
All Changes must live in a release for at least a week
Before they are backported to lts-staging
Stop! Demo Time.
When we are ready for an LTS release
We branch off of v4.x
And cherry pick commits from v4.x-staging
How do we know which commits to cherry-pick?
Github Labels
- Semver Major
- Semver Minor
- lts-watch
- dont-land
Tools
Release tools
- branch-diff
- changelog-maker
- scripts
What is a breaking change?
How do we avoid breaking changes?
CI
Smoke Testing
CITGM found failures the week of Feb 4
Jade moved orgs but didn't update their package.json
Before Change
> var parse = require('querystring').parse;
> parse('%p=123', undefined, undefined,
> {maxKeys: Infinity}).length;
< 1After Change
> var parse = require('querystring').parse;
> parse('%p=123', undefined, undefined,
> {maxKeys: Infinity}).length;
< 0
Smoke Testing Saved the Day!
While the change was on master
It had not yet made its way to a release yet
As such we were able to land a fix
before it hit user land!
CITGM has found all sorts of weirdness
Ask me after and I'll tell you where to find my journal
So Which Version Should You Use?
v4.x (imho)
Why?
- Longest support cycle
- closest to master of LTS releases
- least likely to break your app in production
Do I have to?
Nope!
v6 comes packed with v8 5.1
And with that lots of es6 goodies
Next month v6
will become LTS
Where it will have a 30 month Support Cycle
Be prepared for breakages
If you are an early adopter
Thank You
