►
From YouTube: Node.js Release Working Group Meeting - 21 May 2020
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
So
the
first
item
on
the
agenda
today
is
issue
567,
which
is
the
release
plan.
We
have
releases
scheduled
up
until
june.
I
think
14-3
went
out
yesterday,
I'm
not
sure
anything
else.
Anyone
wants
to
mention
about
that
release
or.
A
I
think
there
was
a
regression
in
14-2
that
is
now
fixed
in
14-3,
but
I
think
we're
gonna
try
and
land
that
patch
in
a
non-breaking
way.
It's
the
windows
standard
out
issue,
but
we're
gonna,
try
and
resolve
that.
A
B
I
mainly
pulled
into
the
agenda
because
there's
a
very
small
time
window
that
this
is
actually
going
to
affect
releases,
so
it
basically
says
that
if
we
are
going
to
release
a
fix
on
release
lines,
whether
that's
in
a
existing
planned
release
or
not,
basically
things
will
start
going
wrong
in
this
particular
time
zone
from
the
24th
of
may
and
then
we'll
correct
itself
on
the
31st.
So
if
we
don't
do
anything
by
the
31st,
this
issue
is
sort
of
closed,
as
in
we
just
were
too
late.
B
B
B
A
Yeah,
so
it
seems
like
our
comment
on
this.
One
would
be
like
we
missed
a
window
to
get
this
out,
but
it
would
be
good
to
correct
it
for
the
people
operating
on
time
zones
like
historic
times.
A
A
B
Yeah,
I
guess
put
it
in
there,
put
it
in
the
in
in
that
issue
and
see
if
anyone
objects.
I
guess.
A
Yep
I'll
just
say,
we
have
no
plan
scheduled
releases
before
the
24th.
B
A
A
B
A
If
we're
not
putting
this
out
as
a
like
a
emergency
fix,
I
guess
we
may
as
well
abide
by
the
must
be
in
14
for
a
couple
of
weeks.
First
rule.
A
A
B
B
I
did
put
some
history,
so
we
did
do
it
from
the
npm
six,
where
npm
six
was
deemed
to
be
a
very
small
delta
over
mpm5
in
terms
of
braking
changes,
so
we
actually
deemed
npm
six
symbol
minor
for
node
and
that
did
go
out
in
node,
ten
and
eight,
I
think
so.
During
during
node
ten
and
node
eight,
we
did
bump
npm
from
npm
five
to
npm
six,
the
only
other
occasion
where
we
bumped
npm
and
an
npm
major
was
in
0.10.
B
B
B
Because
note
14
is
already
out
there
with
mpm6
in
it
and
we
would
generally
not
want
to
put
something
breaking
in
there
unless
there
was
a
reason
like
a
security
fix
or,
and
that
is
that,
probably
the
only
reason
we
do
it
normally.
B
So
well
all
right,
so
I
wrote
in
I
wrote
down
there
when
we
moved
npm
from
five
to
six
and
then
the
only
other
occasion
I
could
recall
was
when
we
went
from
npm
1
to
npm
2
in
node
010,
which
was
in
four
or
five
years
ago.
I,
I
don't
know
if
you
can
recall
any
other
occasions
where
we've
gone
changed
the
npm
version
during
a
release
line.
So
we've
we've
done
it
past.
B
You
know
just
before
we
cut
a
major
but
during
the
lifetime
of
the
major,
but
I
think
those
are
the
only
two
that
I
can
recall.
C
C
C
So
I
guess
like
for
me
one
of
the
things
that
I
think
would
be
really
important
would
be
a
combination
of
like
on
one
hand,
not
just
breaking
people
and,
like
people
have
npm
in
their
pipelines.
Roy
is
here
and
may
be
able
to
give
more
insights.
C
I
know
even
for
like
google,
for
example,
like
we
used
npm
in
the
pipeline
for
like
part
of
our
deployment
or
like
build
packs
that
are
like
cloud
native,
build
packs,
rely
on
npm,
so
changing
the
major
version
if
it
breaks
that
could
be
very
disruptive.
C
The
flip
side
is,
I
don't
know
what
kind
of
lts
process
you
all
are
planning,
and
that
would
be
good
to
know,
but
also
just
kind
of
like
if
npm
7
is
what
will
be
primarily
maintained
and
used.
If
it
is
at
a
certain
degree
of
stability.
I
think
it
may
be
prudent
for
us
to
land
it
if
it's
proving
not
to
be
very
disruptive
in
the
ecosystem.
D
So
basically
I'm
kind
of
torn
on
this,
because
the
reality
is
that
there
are
going
to
be
like
a
lot
of
small,
very
subtle,
like
subtle,
breaking
changes
that
like
might
affect
the
ecosystem,
like
on
top
of
my
mind,
things
like
installing
peer
dependencies,
like
npm,
runs,
switched
around
a
bunch
of
environment
variables.
It
sends
two
scripts
that
might
break
again
in
subtle
ways
like
pipelines,
so
that
kind
of
scares
me
but
at
the
same
time
there's
so
many
good
stuff.
Like
so
many
improvements.
D
So
many
many
new
features
and
it
will
be
a
shame
to
kind
of
like
not
have
that
for
ages
until
like
people
actually
move
to
no
15
16
right.
D
So
I'm
kind
of
over
the
fence,
but
to
give
maybe
some
idea
of
a
timeline
we're
discussing
like
we're,
hoping
to
send
the
beta
version
out
really
soon
like
early
summer,
so
we're
kind
of
aiming
to
that.
But
there's
no
word
written
in
stone
yet
so,
like
just
that's
just
a
vague.
D
B
B
I
guess
one
of
the
things
I
was
trying
to
point
out
in
the
issue
that
was
raised
in
the
tfc
repo
was
there.
There
was
a
line
about
getting
it
in
before
14
goes
rts,
but
from
my
point
of
view,
I
don't
think
it
really
matters
if
node
is
no
14
is
either
current
or
in
lts
or
active
lts.
That
is
in
terms
of
you
know.
B
If
we
were
going
to
land
npm
seven
in
it,
the
only
difference
without
being
in
lts
would
be
that
we
would
then
want
the
update
to
live
in
current
for
two
weeks,
and
that
might
be
preferable
for
something
like
this
that
we
would
want
it.
You
know
in
the
current
release
for
two
weeks
before
putting
it
into
an
lcs
release,
just
just
for
the
just
because
of
the
risk
factor.
D
Yeah
definitely
yeah,
but
I
think
my
takeaway
would
be
like.
Let's
maybe
like
it
would
be
a
prudent
to
wait
for
the
npm
beta
like
to
be
out
and
collecting
data
from
users
see
how
much
of
a
disruptive
release.
It
really
is
right
from
a
breaking
chain's
point
of
view.
B
Yeah,
I
have
no
problems
there
I
mean
I
I
obviously
it's
easier
to
be
cautious
and
users
can
always
install
npm
themselves
outside
of
the
actual
releases
we
do.
So
all
we're
talking
about
here
is
bundling
it
in
the
actual
node
releases,
but
it's
a
bit
harder
to
bundle
something
and
then
go
backwards
than
it
is
to
bundle
something
and
potentially
update
it
to
a
new
version.
A
D
Well,
as
far
as
I
know,
yes,
I
think
we'll
be
maintaining
six
for
a
while
still,
but
I
don't
really
know
long
term
plan
what
it
looks
like
to
be
honest.
B
D
A
When,
once
once,
I've
finished,
we've
finished
a
meeting
I'll
paste
in
all
of
the
comments
that
richard
mentioned
and
links
to
our
historic.
D
Sure
yeah,
but
if
any
other
question
I
think
this
is
like
kind
of
my
point
of
view
yeah.
I
think
the
most
prudent
thing
is
to
wait
for
for
the
results
from
the
npm
data
go
out.
A
B
Yeah,
I'm
cool
with
that.
I
I
just
wanted
to
put
this
out
on
here,
because
the
issue
was
raised
in
the
tfc
replay,
but
obviously
it
does
affect
releases,
so
I
kind
of
figured
we
would
want
to
discuss
it
amongst
ourselves
anyway.
A
No
one
thing
I
will
mention
is,
I
think,
both
reuben
and
I
today
had
the
mission
of
trying
to
clear
out
some
old
release,
issues.
A
I
think
he's
closed
off
quite
a
few
stale
ones,
but
if
anyone
has
any
disagrees
that
this
should
have
been
closed
and
feel
free
to
reopen,
I
did
do
and
like
scan
for
all
of
our
open
issues.
A
lot
of
them
are
about
creating
documentation.
A
Yeah
sure,
thanks
richard
and
yeah,
we've
got
a
lot
of
things
like
onboarding
information,
a
document
how
to
back
port
majors.
A
Create
off-boarding
documentation
and
policy.
Oh
this
is
one.
I
went
to
action
today
to
rename
the
citjim
team
to
release
automation,
but
I
don't
think
we've
audited
the
current
sichum
team
membership
and
I
wasn't
sure
I
should
do
it
because
I'm
not
in
the
sichum
team,
so
I
wondered
if
someone
else
would
be
who
is
in
sichuan
would
be
happy
to.
A
I
didn't
realize
how
small
deception
team
was
until
I
opened
up
the
members
list
today.
A
A
Oh,
it's
the
big
1217
miner.
That
michael
was
working
on.
As
a
reminder,
I
need
to
check
out
the
pr
and
review
I
think.
A
Is
that
the
that's
the
one
where,
in
the
release
mentoring,
we
went
through
each.
A
B
Yes,
the
one
of
the
nipi
ones
was
reverted.
A
Tbd,
if
needed,
I
was
going
to
prepare
a
10
if
the
time
zone
stuff
was
ready,
but
it
didn't
look
like
it
was,
and
so
I'd
rather
wait
for
the
decision
on
the
14
for
the
time
zone.
And
if,
if
people
do
object
to
waiting,
then
I
I
can
sign
up
to
do
a
10
release.
But
I
feel
like
this
can
just
be
pushed
out
until
we
need
to
do
a
release.
A
But
oh
the
napi
exemption,
I
don't
know
if
we
should
raise
an
issue
to
add
that
back.
I
I
deleted
it.
I
kind
of
remember
deleting
it,
but
if
we
want
the
do,
we
want
to
explicitly
call
this
out
again.
B
It's
mainly
just
to
clear
up
confusion
as
to
when
an
api
changes
can
land
or
not.
There
does
seem
to
be
again.
This
comes
back
down
to
the
lts
phrases
and
people
just
trying
to
cram
things
in
before
something
changes
phase.
So
I
think
there
was
at
least
one
or
two
issue:
pull
requests
where
it
was.
We
need
to
try
and
get
this
in
quickly
so
that
we
can
get
it
in
before
10.
It
goes
into
maintenance,
but
I
think
the
reason
this
all
came
with
that
was.
B
B
Maintenance
for
compatibility
reasons,
but
then
yes,
because
we
deleted
the
words.
I
couldn't
quote
anything
and
it's
always
it's
always
nicer
when
you
can
quote
policy
rather
than
just
state
it
and
accept
it.
B
B
B
And
maybe
maybe
it
might
make
sense
for
the
lts
things
to
to
restrict
or
not,
but
basically
say
you
know,
I'd
either
leave
it
to
it.
You
know
as
a
sort
of
an
exemption,
but
still
at
our
discretion
or
or
if
you
want.
You
know,
if
you
maybe
make
that
distinction
between
stable
things
and
experimental.
A
Okay,
I
think
I
will
open
an
issue
to
say,
add
an
api
exemption
back
and
point
to
this
discussion
because,
maybe
even
like
I
know
michael
may
be
willing-
or
we
could
maybe
even
go
speak
about
a
nepi
meeting
to
see
what
they
think,
whether
they
agree
that
experimental
things
should
be
in
lts,
or
they
might
have
some
very
strong
reasons
why
it
should
be
so.
A
B
And
it
would
be
good
to
set
their
expectations
because
I
you
know
I
I
do
see
them
opening
prs
to
back
port
and
api
things
into
10
and
12.,
and
then
we
sort
of
just
the
communication
around
when
windows
are
expected
to
land
on
things.