►
From YouTube: Node.js Releases, How Do They Work? by Myles Borins, IBM
Description
Node.js Releases, How Do They Work? - Myles Borins, IBM
Node.js is growing up, and with that comes the responsibility of proper legacy support. As of Node.js Argon (v4.2.0) there is an official Long Term Support release cycle that lasts for 30 months!
How does a project moving at the pace of node maintain multiple release lines? How does a commit get backported? How is a release actually made? You will learn all this and more on this weeks episode of "Node.js Releases, how do they work?".
A
Hey
everyone
thanks
so
much
for
coming
before
I
get
started.
Just
a
quick
round
of
applause,
for
everyone
is
doing
such
hard
work.
You
may
not
know
it,
but
there's
a
couple
people
in
the
back
there
doing
all
this
video
stuff
handful
people
in
the
back
there
making
sure
everything
is
working.
All
the
people
who
put
in
a
hard
time
so
just
write
a
lot.
A
Cool
so
howdy.
This
is
I,
usually
start
every
presentation
with
this
and
usually
have
a
screen
behind
me.
So
it's
a
little
easier,
but
I'll
do
this
from
the
corner.
I'll,
try
not
to
skip
it,
but
I,
usually
just
like
turn
my
back
to
the
audience.
I.
Look
at
this
I
put
up
my
hands.
I
just
do
this
and
it
calms
me
and
then
you
laugh
and
I
no
longer
feel
nervous
and
then,
when
you
stop
laughing
I'll,
stop
I
cool
we're
good.
A
So,
as
I
said,
I'm
miles,
I
work
at
a
small
disruptive
startup
called
IBM
contributing
to
a
project
called
nodejs.
Many
of
you
are
familiar
with
the
opinions
in
this
talk
are
my
own.
You
know
just
thrown
that
out
there
so
version.
How
do
they
work
so
versions?
There
are
a
lot
like
magnets
and
you
know,
stick
with
me
on
this
versions
are
a
lot
like
magnets,
primarily
that
many
people
are
pretty
confused
about
how
they
work.
But
you
know
this
stuff
is
really
complicated.
There's
a
lot
of
moving
parts.
A
There's
a
lot
of
different
things
going
on,
but
something
that's
important
to
remember
is
that
you
don't
actually
need
to
understand
everything
to
contribute
in
a
meaningful
way
by
just
knowing
a
small
part
of
the
process,
you
can
contribute
in
a
meaningful,
well,
meaningful
way.
You
don't
need
to
know
how
the
whole
node.js
repo
works
in
order
to
send
an
update
to
tests,
and
you
don't
need
to
know
what
every
single
commit
does
in
order
to
make
a
release.
A
So
we're
going
to
start
from
small
piece
and
we're
going
to
build
it
up
and
see
how
we
get
into
a
more
complicated
system.
So
we're
going
to
start
with
December
can
I
just
see
a
quick
raise
of
hands
how
many
people
in
the
audience
have
heard
of
cember
before
and
to
keep
your
hands
up
if
you
use
summer
and
the
projects
that
you
manage
and
keep
your
hands
up.
If
you,
a
hundred
percent,
know
exactly
what
sin
ver
means
to
the
spec
cool,
so
semantic
versioning.
As
you
see
here,
three
digits.
A
A
So,
let's
dig
into
each
of
these
and
talk
about
what
they
mean
so
a
patch.
What
is
a
patch
a
patch
is
any
change
that
does
not
change.
Functionality
does
not
change
behavior
I
guess.
Maybe
functionality
is
not
the
right
word
to
use.
Let's
stick
to
behavior
a
patch
of
something
that
does
not
change
behavior.
It
does
not
add
new
functionality,
so
this
can
be
an
update
to
a
test.
This
could
be
an
update
to
documentation.
This
could
be
a
performance
improvement.
This
could
be
tooling
changes.
A
This
could
be
a
new
tap
output,
there's
all
sorts
of
things
that
can
come
in
as
a
cember
patch
as
long
as
it's
not
changing
the
behavior
and
it's
not
changing
and
adding
new
features,
and
if
you
see
a
release
come
out,
that's
just
a
patch
release,
just
updating
that
last
digit.
You
should
generally
expect
that
there
are
not
going
to
be
changes
in
behavior
and
new
stuff,
and
you
can
just
update
it
accordingly.
A
This
is
part
of
the
reason
why
we
glob
a
10pm
so
that
we
automatically
get
updates
when
we
do
an
NPM
install
and
don't
lock
to
specific
versions.
One
other
thing
that
can
come
in
as
a
patch,
which
is
really
important,
are
any
sort
of
security
changes.
This
is
really
important
if
the
security
changes
are
not
changing
anything,
you
know
you
can
rely
on
a
patch
and
generally
making
your
code
more
reliable
and
faster.
A
What's
a
minor,
so
a
minor
is
any
change
that
adds
new
functionality
without
changing
behavior.
So,
for
example,
the
v8
inspector
coming
into
node
could
be
considered
December
minor
improvement.
If
it
didn't
change
any
of
the
interfaces
for
the
already
existing
debugger
and
it's
slowly
a
new
feature,
you
can
bring
it
in
other
examples
of
things
that
can
come
in
as
minors
are.
You
know
new
methods
on
a
class
as
long
as
they're,
not
changing
the
native
layer
where
any
ABI
changes
are
considered.
A
A
So
when
we
introduced
the
new
real
path-
implementation
in
version
6,
for
example,
part
of
the
reason
why
we
ended
up
reverting,
it
was
because
it
introduced
potentially
new
throwing
errors
which
in
turn
then
broke
node,
glob
and
coming
grounding
afterwards.
If
you
want
to
hear
more
about
how
that
turtled
all
the
way
down,
but
it's
really
important
to
make
sure
that
we're
not
changing
that
contract.
A
This
would
be
particularly
interesting
for
the
it
would
allow
us
to
do
internationalization
of
error
messages,
which
I
think
would
be
really
really
cool.
So
note
has
a
number
of
different
release
lines.
Our
current
release
line
is
v.
Seven
point
two
point:
zero.
We
have
active
LTS,
which
is
the
6.9
point,
1
and
v.
Four
point
six
point:
two
and
maintenance:
LTS
is
0
12
17.
What
you're
going
to
noticed
is
no
10
is
no
longer
maintained
for
better
for
worse.
A
We
are
no
longer
maintaining
it
and
v-0
12
is
going
to
be
end-of-life
December
31st,
it's
time
to
upgrade
if
you're
still
running
on
either
of
these
versions.
One
of
the
primary
reasons
why
we
decided
to
deprecate
them
was
due
to
openssl
no
longer
maintaining
the
version
of
up
in
a
Cell.
That's
depended
on
in
those
versions,
but
also
the
Delta
between
0,
10
and
12,
and
what
we
have
going
on
in
foreign
hire
is
so
huge.
A
It's
actually
a
pretty
non-trivial
maintence
burden
on
the
project
to
maintain
those
two
versions,
but
so
I
talked
about
version.
4
and
I
talked
about
versions,
10
and
12,
but
you
know
what
what
happened
with
1
through
3,
and
you
know
what
is
the
deal
with
12,
so
notes
started
with
an
alternating
release.
Schedule
so
even
was
stable
and
odd
was
unstable,
so
I
started
using
node
in
0.6
and
when
I
started
using
it
0.6
was
the
stable
branch
and
0.7
was
the
unstable
branch.
A
New
features
and
new
experiments
would
land
in
07
and
06
was
treated
as
you
know,
holy
and
when
it
was
ready
for
a
major
update,
they
bumped
07
208
and
then
started
9,
as
essentially
the
dev
branch.
Now
this
is
a
system
that
works,
but
there's
a
couple
problems
with
this.
One
of
them
is
the
lack
of
the
granularity
of
the
major
version
number
so
by
sem
vers
rules.
A
If
you
do
not
have
a
cember
major
number
and
it's
0,
then
you
actually
just
shift
everything
over
and
the
cember
minor
reflects
some
ver
major
and
december
patch
for
flex,
ember
minor
and
then
patches
are
just
out
the
window
and
they
come
as
semper
minor
releases.
You
know
for
a
project,
that's
early,
such
as
node
when
it
was
starting.
That
kind
of
granularity
may
not
exactly
be
necessary,
but
it
can
create
this
problem.
It
is
kind
of
like.
When
do
we
go
1
point
0
problem
personally.
A
I
start
all
my
projects
now
1
point
0
and
the
reason
for
that
is
that
I
don't
want
to
ever
start
having
that
debate
of
like.
Are
we
stable
enough
to
go
to
one
and,
like
you,
create
this
really
problematic
narrative
when
you
kind
of
have
that
first
0
there
and
that's
one
of
the
things
that
was
a
problem,
it
was
taking
a
really
long
time,
40
12,
to
come
out.
00,
10
I
think
we
is
the
main
stable
branch
for
at
least
two
years
correct
me
afterwards.
A
If
I
was
wrong
on
that,
but
it
was
taking
a
long
time
to
move
to
12
and
it
wasn't
really
clear
when
version
one
was
even
going
to
come
out,
so
the
project
was
forked
in
December
of
2014.
It's
pretty
amazing
to
think
that
his
almost
two
years
ago
now
that's
Wow,
but
it
was
released
as
version
1,
and
this
is
this
is
particularly
interesting
because
it's
actually
an
appropriate
use.
A
December
the
project
was
forked
semper
major
change,
you
know
so
they
bumped
to
one
and
the
project
started
moving
forward
using
cember
proper,
so
v-0
12
was
released
in
February
of
2015.
Just
before
node
summit,
it
primarily
included
a
small
update
to
v8.
The
version
of
the
eight
that
0-10
was
running
on
was
another
reason
for
the
fork.
A
People
were
just
not
happy
running
on
an
old
version
of
the
eight,
so
the
v12
was
released
with
a
slightly
updated
version
of
the
eight
and
also
a
handful
of
internationalization
updates,
but
it
did
not
include
any
of
the
work
that
was
going
on
an
I/o
at
the
time.
So
during
this
time
versions,
one
through
three
we're
all
part
of
the
I
ojs
project.
If
I
recall
correctly,
and
if
you
find
a
Jeremiah
out
there,
fish
rock
one.
Two
three
on
github
is
at
the
conference.
A
Their
release
process
at
the
time
was
kind
of
just
you
know,
cut
whatever
is
in
master.
So
if
we've
got
several
major
changes
on
master,
then
we
cut
assembler
major.
If
we've
got
minor
changes,
we
cut
a
semper
minor
and
some
of
that
ethos
still
lives
on
in
our
current
release
cycle,
which
we'll
talk
about
in
a
second
so
notice
put
into
a
foundation.
The
node
foundation,
which
you
know,
is
the
foundation
behind
this
event
and
the
projects
were
merged.
A
As
version
four
point:
oh
in
September
of
2015
four-point-oh
being
the
first
version
that
had
LTS
support,
which
we
can
see
here.
This
is
our
LTS
release
schedule.
You
can
see
that
in
October
of
2016
v,
0
10
ended
its
maintenance
cycle
and
0
12
ended
its
maintenance
cycle
in
December.
These
two
are
special
cases
and
not
part
of
the
new
release
process
that
we
have.
That
offers
a
30-month
LTS
support
cycle,
LTS
being
short
for
long-term
support.
So
this
is
part
of
a
greater
contract
that
we
have
to
users
to
say:
hey.
A
If
you
to
build
input
code
on
node,
we
can
guarantee
you
support
for
the
version
of
note
that
your
code
is
running
on
for
essentially
three
years,
you
have
six
months
of
a
branch
being
used
as
current,
and
if
it's
an
even-numbered
branch,
it's
then
going
to
have
a
30-month
LTS
support
cycle.
18
months
as
active
and
12
months
as
maintenance,
our
odd-numbered
releases
you'll,
see
have
a
six
month
support
cycle
and
then
there's
like
a
small
maintenance
period
afterwards,
where,
if
there
is
any
really
big
problems,
we
will
do
new
updates.
A
But
the
big
change
here
is
that
we
have
this
cycle
that
guarantees
that
we're
moving
forward
with
semper
major
changes.
There's
no
waiting
for
some
esoteric
thing
to
happen
before
we
can
move
forward,
and
this
gives
us
a
really
good
way
to
schedule
and
plan
changes
that
are
coming
and
to
really
think
about
it.
So
an
uneven
release
such
as
7
is
a
great
place
where
we
can
put
changes
that
are
potentially
more
disruptive
because
we
can
revert
them
in
seven
and
then,
by
the
time
we
get
to
eight.
A
If
the
revert
december
major
that
we'll
never
make
it
into
LTS.
So
this
gives
us
a
bit
of
granularity
and
in
a
year
we're
going
to
have
two
different
major
versions
or
I
mean
technically
three.
If
you
thinking
about
the
bookend-
but
this
gives
us
a
really
great
granularity
on
how
we
do
releases-
how
we
think
about
things
landing
and
how
we
can
guarantee
that
we're
not
breaking
stuff
for
people.
So
what's
a
current
release
line,
the
current
release
line
is
the
main
release
line
that
we
use
for
all
versions.
A
Maintenance
LTS,
on
the
other
hand,
no
longer
has
that
active
back
boarding
of
things
from
new
releases,
but
we
will
continue
to
support
it
during
a
maintenance
period
with
any
major
security
vulnerabilities
or
any
major
regressions
that
are
found.
So
you
know
if
it's
three
months
after
its
moved
into
maintenance,
and
we
find
a
huge
bug,
we're
going
to
do
a
release
at
any
time
that
there's
like
an
open,
SSL,
CVE
or
some
sort
of
v8
change,
we're
going
to
continue
to
backport
that
you
know
during
that
whole
30
month
cycle.
A
So
for
reference
version,
four
is
about.
You
know,
13
months
into
its
LTS
cycle,
so
it
has
another
five
months
before
it's
going
to
finish,
being
an
active
LTS
and
moved
into
maintenance
mode.
What
about
master
pretty
much
every
pull
request
that
comes
in
lens
directly
into
master.
We
do
not
maintain
a
dead
branch.
What
we
do
is
we
have
master
and
we
cherry
pick
and
back
port
commits
directly
from
master
to
all
the
release
lines.
So
how
do
we
manage
all
of
this?
Mostly
magic?
More
specifically
get
magic.
A
We
use
a
lot
of
different,
get
tooling
to
manages
and
scripts
and
when
I
find
particularly
cool
about
get
magic
is
since
it's
magic
with
trees
basically
makes
ourselves,
but
so
we
maintain
release
branches.
We
have
a
release
branch
for
the
12
4
6
&
7.
These
are
all
branches
that
live
in
our
repo.
We
also
have
staging
ranches
and
each
of
these
staging
branches
we
put
commits
on
before
we're
going
to
do
a
release
that
we
know
that
we
want
to
have
landed
in
those
releases.
A
A
So
let's
look
at
the
node
repo
here
and
let's
look
at
our
pull
request
and
I'm
going
to
show
you
a
little
bit
of
what
what
the
process
of
back
porting
something
looks
like
so
go
here
to
labels.
We
can
look
at
LTS
watch
v
6
and
if
we
go
to
closed
here,
are
all
of
the
pull
requests
that
have
landed
on
to
master
that
have
not
yet
been
backported
to
an
LTS
release
and
so
I'm
going
to
pick.
A
You
know
a
random
commit
that
I
definitely
have
not
reviewed
before
and
made
sure
that
it's
going
to
work.
Well.
Take
this
one
right
here
now
this
one's
a
little
knew
it
started
in
October
fifth,
but
it
only
landed
two
days
ago.
But
what
I
think
is
important
about
here
is
to
actually
look
at
the
changes,
and
this
is
something
we'll
think
about.
Well,
it's
actually
mostly
updating
virus
to
const
and
changing
equal
to
strict
equal,
and
that's
really
all
it's
doing,
and
it's
all
inside
of
the
test
suite.
A
So
none
of
this
is
affecting
the
performance
of
the
project
itself.
This
is
just
stuff.
That's
going
to
make
our
CI
better,
so
what
we
can
do
is
we
can
go
and
we
can
take
the
commit
and
we
can
take
a
look
at
it.
Here's
the
commit
that
came
in
a
little
fun
thing
on
github
that
you
may
not
know
about
is,
if
you
add
dot
patch
to
the
end
of
any
commit
it's
going
to
give
you
a
get
mail
message,
which
is
the
way
in
which
the
colonel
maintains
originally
handed
patches
around.
A
It
will
allow
you
to
patch
directly
onto
the
head
of
a
branch,
not
cause
any
weird
branching
and
makes
it
really
great
for
bisect
and
get
bisectors
kind
of
the
best
thing
that
ever
happened
to
computers,
in
my
opinion,
so
what
we
can
do
is
we
can
hop
here
into
the
staging
branch
and
call
Patchett,
which
is
a
little
alias,
that
I
have
for
a
handful
of
git
commands.
It's
going
to
curl
this
this
line
adding
patch
to
the
end.
A
A
And
we
update
upstream,
we
can
go
back
into
this
into
this
thing
and
we
can
remove
the
LTS
watch
label
from
v6
and
say
that
it
was
landed.
So
one
of
the
things
that's
cool,
that's
happening
now
is
we
actually
have
two
LTS
releases
that
we're
managing
at
the
same
time
and
it
turns
out
that
it
doesn't
actually
take
twice
as
much
time
to
do
it.
So
now,
we've
got
this.
I
can
just
go
here.
Grab
that
same
python
command
that
I
had
just
used
copy
it
paste.
It
worked
push
ups,
tremely,
just
updated
v4.
A
So
now
we've
gone
through
and
we've
audited
this
command.
We've
landed
the
commits
into
into
our
staging
branches
for
both
of
those
LTS
releases
and
not
the
next
LTS
release,
which
is
currently
in
a
release
candidacy,
but
in
a
following
LTS
release
that
update
to
the
test
will
make
its
way
into
the
project.
When
we
do
this,
we
have
a
bat.
We
have
a
backlog
of
you
know
of
between
300
and
500,
commits
in
a
month
that
we
need
to
do
this
with,
but
we're
constantly
going
through.
That
was
an
example
of
one.
A
That's
really
easy
to
audit
and
make
the
decision
to
backport,
but
sometimes
when
things
are
a
little
bit
more
complicated,
we
bring
in
other
individuals
to
help
us
with
it.
So
when
we're
ready
for
a
release,
we
branch
off
of
one
of
the
release
branches,
those
release
branches-
are
sacred.
We
do
not
force
push
to
them.
We
do
not
modify
them,
they
are
only
updated
by
the
releases
and
the
head
of
it
will
always
be
the
head
of
the
last
release
of
that
release
line.
A
How
do
we
know
which
commits
the
cherry
pick
github
labels,
so
we
have
a
github
level
label
for
sin,
ver
major
press,
ember
minor
for
LTS
watch
and
for
don't
land
all
those
different
labels
that
you
saw
going
on,
and
then
we
have
tools
tools
such
as
branch
diff.
So,
if
you're
doing
a
git
diff
a
gift,
if
is
actually
going
to
be,
comparing
the
two
trees
and
letting
you
know
what
the
difference
is
in
the
file
system
of
those
trees,
that's
not
what
we
want
to
know
when
we're
doing
back
ports
for
LTS.
A
Well,
we
care
about
for
backports
of
LTS
our
atomic
units
of
change.
We
care
that
this
specific
change
with
this
specific
title
and
metadata
exists
on
the
other
branch
and
make
touch
completely
different
code,
and
it
may
do
things
slightly
differently,
so
with
branched.
If
what
we
can
do
is
branched,
if
we'll
go,
it
will
compare
the
titles
of
the
commits
the
metadata
of
the
commits
and
then
give
us
a
list
of
commits
which
don't
exist
on
that
branch.
So,
for
example,
we
can
go
here
into
v6
and
we
can
say
you
know.
A
So
we
can
do
a
branch
sniff
and
we
can
say,
hey,
you
know
from
v6
staging
to
master,
and
this
is
going
to
take
a
second,
but
it's
going
to
go
through
and
it's
going
to
get
a
list
of
all
the
commits
that
exist
on
master
that
don't
exist
on
v6s
staging,
and
so
all
these
green
ones
that
you
can
see
here
are
all
December
major
changes.
So
we
can
add
a
number
of
filters
to
say:
hey,
we
don't
care
about
any
commit
that
sin
ver
major.
A
We
don't
care
about
any
commit
that
has
a
label
for
LTS
already
and
we
don't
care
and
we
can
just
keep
adding
labels
like
to
filter
out
the
release
commits
and
eventually
you
can
go
and
start
making
making
these
audit
lists,
and
we
can
see
right
here
the
last
audit
list
for
v6.
These
are
all
commits
that
have
not
yet
been
labeled.
The
need
to
be
audited.
We'll
wait
a
couple
weeks
because
we
caught
up
to
where
the
latest
release
was
for
v7.
A
So
once
the
next
v7
release
comes
out,
we'll
start
auditing
again
and
catching
up.
So
we
have
changed
log
maker
as
well,
which
is
built
on
branch
diff
and
that
automates
the
changelog
process,
and
we
have
a
number
of
scripts
that
we
use
for
releases
as
well.
So
I'm
gonna
have
to
go
through
this
really
quickly
because
I'm
running
at
a
time,
but
what's
a
breaking
change.
When
we
talk
about
sin,
ver,
major
and
I,
just
I
love
this
jeff.
I
really
hope.
A
No
one
got
hurt,
though,
but
so
assembler
major
change
is
any
breaking
change.
Any
behavior
changes.
We
were
talking
and
there's
ways
to
avoid
these
breaking
changes.
The
number
one
one
that
you
can
think
of
is
CI,
but
another
thing
that
we
do
is
what's
known
as
smoke
testing
and
we
have
utility
called
canary
in
the
gold
mine
canarian.
The
gold
mine
will
grab
the
test.
Suites
and
tar
balls
of
the
top
70
modules
in
the
ecosystem
will
run
all
the
tests
and
then
it
will
report
breakages.
A
This
is
an
example
of
where
we've
seen
breakages
breakage
on
jade
and
a
breakage
on
body.
Parser
turned
out
Jade
had
to
change
the
name
to
pug
I'm
kind
of
bitter
about
that,
but
they
didn't
update
their
package.json
sore
algorithm
for
resolving
tar
balls
is
broken,
so
he
sent
a
quick
poll
request
and
it
was
updated.
The
change
to
body
parser
was
a
little
worse
body.
Parser
is
built
on
top
of
query
string
and
it's
used
inside
of
Express
for
pretty
much
any
body
they
can
parsing.
A
So
this
is
code,
that's
really
really
hot,
and
there
was
an
optimization
here
on
on
split.
Basically,
every
time
that
split
was
called,
we
were
calling
split
and
then
we
were
doing
a
comparison
for
max
length
and
then
shortening
the
string.
This
wasn't
super
optimized.
This
creates
lots
of
extra
garbage.
It's
not
the
best
thing
to
do
so.
All
we
did
is
we
realize
you
can
pass
an
argument
of
max
keys
to
split
and
then
that
can
all
be
handled
in
in
v8
land.
A
What
they
didn't
account
for
was
infinity,
because
it
turns
out
that
split
actually
infers
infinity
to
an
integer
and
when
infinity
is
inferred
to
an
integer,
it's
zero.
So
before
the
change
you
know
you
would
get
a
length
of
one
for
infinity
after
the
change.
You'd
get
a
length
of
the
era
of
zero.
So
what
was
really
interesting
here?
We
were
not
testing
this
education
node,
but
body
parser
was
so
we
broke
body
parsers
tests.
We
were
able
to
go.
A
Take
that
test,
make
it
abstract
enough
that
it
wasn't
just
for
node,
move
that
test
into
node
and
make
a
fix,
and
it
was
like
you
know,
one
line
and
the
smoke
testing
saved
the
day.
The
thing
that
was
the
coolest
is
well.
The
change
was
on
master.
It
had
not
made
it
to
a
release,
so
it
actually
never
ended
up
in
user
land
and
we
could
land
a
fix
before
it
even
got
out
into
the
wild
okay.
So
really
quickly.
A
What
version
should
you
use
before
had
has
had
a
while
to
stabilize
on
LTS
and
v6
has
been
on
LTS
for
about
a
month
and
it's
getting
ready
for
its
third
release
and
v7
is
always
getting
the
latest
and
greatest.
So
why
use
you
for
hardened
by
the
ongoing
LTS
process?
It
is
going
to
be,
in
my
opinion,
the
most
stable
of
all
the
releases
that
we
have
right
now.
So
if
you
already
have
something
working
on
for
we,
you
know
there's
probably
no
reason
to
update
it
immediately.
A
You
may
want
to
look
into
it
because
4
is
moving
into
maintenance
in
the
next
six
months,
but
you're,
probably
good
6,
has
the
longest
support
cycle
of
any
of
the
LTS
releases
out
there
right
now.
So
if
you
get
on
26
you're
going
to
have
a
longer
support
cycle,
it's
the
closest
to
master
of
all
the
LTS
releases,
which
means
it
comes
with
v8
5.1,
which
is
a
much
broader
support
for
es6
than
what's
on.
V4
also
has
the
inspector
api,
which
is
super
rad.
Do
you
have
to
use
LTS?
No
you're
adults?
A
You
can
do
whatever
you
want,
but
you
know
it
comes
with.
V8
5.4
comes
with
a
little
bit
of
es
2016,
it's
the
latest
and
greatest,
but
if
you
use
it
in
production,
I'm
going
to
be
really
really
scared,
so
yeah.
If
you're
going
to
use
v7
production
just
be
prepared
for
breakages.
It's
kind
of
all
that
I
can
warn
you
so
anyways.
Thank
you
very
much
for
the
time
I'm
miles,
and
this
is
sort
of
pepper.
Thank
you.