►
From YouTube: 2021-02-25 - Node.js Release Working Group Meeting
Description
A
Okay,
so
we
are
welcome
to
the
node.js
release
working
group
meeting
on
the
25th
of
february
2021
we're
going
to
work
from
the
agenda.
That's
in
the
node.js
release
repository
and
it's
issue
number
648
before
before
we
get
started.
Are
there
any
announcements
anyone
would
like
to
make
at
the
start
of
the.
A
A
A
A
A
A
Yet
I
think
it
would
be
good
if
we
are
going
to
do
one
and
to
try
and
get
it
out
kind
of
before
note
16
comes
out,
and
so
in
the
march
or
early
april
time
frame
still
need
volunteers
to
carry
that
whole
release
through
to
the
end.
But
I
can
it
is
on
my
list
to
start
building
up
some
back
courts
on
the
staging
branch.
A
C
A
A
Okay,
I
propose
we'll
probably
I
need
to
update
this
table,
because
the
1416
was
the
security
release
and
I
will
probably
because
we're
going
to
need
a
release.
Candidate
phase
bump
the
miner
tentatively
to
the
march
window,
not
give
it
a
static
date,
see
how
we
get
on
with
the
back
courts
over
the
next
week.
A
E
D
A
E
A
E
E
A
Yeah
so
yeah
this
is
trying
to
get
these
landed,
because
now
we
know
the
next
one's
going
to
be
minor.
If
we
can
get
these
landed,
then
maybe
we
can
build
up
enough
to
warrant
getting
the
release
out,
even
if
it's
a
slightly
smaller
release
and
it's
kind
of
opt-in
and
the
things
that
have
been
explicitly
back
ported
or
tagged
lts
watch,
I
think
that's
okay,
but
it'd
be
good
to
get
these
out,
because
people
have
been
waiting
to
see
this
one
from
december,
so
be
good
to
get
them
out.
C
E
A
E
A
Okay,
so
in
terms
of
scheduling
and
we're
all
scheduled
for
15
14,
we
just
need
to
build
up
the
back
ports
and
patches
on
the
staging
branch
and
then
seek
a
volunteer
to
carry
the
release
through
and
12
is
going
to
wait
until
well,
we've
made
a
decision
on
14
and
nothing
to
do
for
10,
so
sounds
good
and
back
to
the
agenda.
It's
not
added
it.
I
don't
think
because.
A
C
A
E
E
What
it's
actually
going
to
look
like
to
people
that
pick
up
the
releases
so
there's?
Obviously
the
side
of
you
know
as
a
releaser.
How
much
effort
do
we
spend
preparing
pairing
the
releases?
Putting
the
releases
out?
You
know
the
actual
mechanics
of
it,
but
then
there's
also
the
if
I'm
in
the
ecosystem
and
I
have
a
module
and
I
need
to
know
what
features
I
can
use.
If
I
want
to
support
you
know
the
different
versions
of
node
or
even
which
version
of
node
should
I
be
supporting.
E
It's
you
know.
The
sort
of
this
proposal
was
no
longer
sort
of
just
december.
It's
kind
of
similar
with
labels
tacked
on
that.
Nothing
else
is
using
in
terms
of,
if
you
pick
up,
say
december
module.
If,
if
you're
following
what
looks
to
be
december,
you
don't
really
have
to
do
things
if
you
are
testing
for
versions
and
that,
but
if
you've
now
got
some
custom
skin
with
date,
stamps
you're
looking
at
slightly
more
complicated
parsings
of
versions.
A
C
Yeah,
I
think
there
is
one
aspect
of
the
of
at
least
the
discussion
here.
I
think
you
might
have
brought
it
up
in
your
comment
path,
but
one
of
the
things
that
would
be
very
nice
from
a
very
practical
releaser
working
group
point
of
view
is
that
the
backboarding
in
the
active
lines
lts,
is
it's
quite
time-consuming
right.
So
improving
on
that
that
I
think
that
is
a
problem
that
we
can
try
to
act
on.
C
So
I
don't
know
if
you
just
try
to
short
and
the
time
frame
of
the
lts,
active
support
or
yeah
or
maybe
create
a
different
system
where
maybe
we
only
backboard
things
that
requested
like
opt-in,
yeah,
yeah,
opt-in,
yeah
make
adoption
like
so
people
have
to
send
the
backboard
if
they
want
to
see
it
landing
in
a
yeah
lts,
or
something
like
that.
I
think
we
can
tweak
the
current
system
rather
than
trying
to
modify
it
radically
right.
E
A
Yeah-
and
I
do
think
if
we
moved
to
opt-in
and
only
backported,
the
things
that
were
explicitly
tagged
with
lts
watch
or
had
been
mentioned
in
this
issue,
is
this
fix
needs
to
land
on
this
release
line
or
have
been
someone's
gone
to
the
effort
to
explicitly
backport
them?
That
would
make
preparing
the
release
of
a
minor
to
me
much
easier,
because
we
don't
need
to
run
branch
diff.
A
We
don't
need
to
triage
the
kind
of
hundreds
or,
however,
many
hundreds
of
commits
there
are
between
current
and
lts
and
that
that
would
make
life
a
lot
easier
preparing
the
summer
miners,
and
I
think
at
that
point
it
wouldn't
be
that
much
different
to
the
patch
like
preparing
a
patch
release,
because
the
list
of
commits
that
we
need
to
pull
in
are
kind
of
already
there.
We
don't
need
to
audit
a
long
list
of
them.
C
E
But
yeah
I
mean
part
of
this
is
trying
to.
I
don't
know
how
we
easily
reach
out
to
capture
the
you
know
the
people
that
are
using
the
releases,
because,
obviously
it's
not
just
us
that
this
affects
this-
affects
the
people
that
this
this
affects.
Anyone
consuming
node
because
effectively
the
whole
versioning
system
changes,
as
well
as
the
release
model,
yeah.
A
One
one
of
the
things
I
think
I
mentioned
on
the
slide
deck
was
like.
Can
we
look
to
the
recent
openjs
survey
to
see
if,
like
there's
any
there
were
some
questions
around
the
lts
policy
in
that
survey
and
see
what
the
sentiment
is?
Are
people
generally
happy
with
it
how
it
is
or
do
some
of
the
problems
people
raise?
So
I
can
take
an
action
to
try
and
maybe
chase
up
when
those
results
are
going
to
be
published
to
see.
If
there's
anything
we
can
pull
from
those.
A
C
A
Yeah
my
thoughts
on
that
would
be
like.
I
see
a
lot
of
collaborators
going
to
a
lot
of
effort
and
contributors
to
back
port
features
and
a
lot
of
users
on
issues
pinging,
saying:
hey,
when's,
this
going
back
to
14
or
when's
this
going
back
to
the
lts,
so
it
must
be
a
desire
somewhere,
but
how
to
quantify
that
into
it's,
a
very
small
subset
or
it's
a
massive
subset.
E
A
A
E
E
The
other
hand,
if
we,
if,
if
we,
for
example,
if
we
rule
out
this
proposal
for
16,
then
that
gives
us
more
time
to
discuss
it
yeah
and
we
don't
feel
pressured
into
making
a
quick
decision
on
it,
because
you
know
we
do
have
a
a
a
window
in
which
16
is
scheduled
and
I'm
not
too
happy
about
moving
moving
that
just
for
the
sake
of
upheaval
yeah.
I.
A
A
Yeah,
I
I
completely
agree
what
we
got
written
down.
I
guess
we've
already
got
16
in
our
table
as
well,
so
I
I
would
definitely
be
inclined
to
say
it's
a
bit
too
short,
a
time
frame
to
change
this
for
16
and
that
definitely
relieves
the
pressure,
because
the
biggest
impact
is
things
being
backported
to
lts,
and
that
almost
gives
us
another
year
to
get
feedback
figure
out.
The
problems
figure
out
whether
this
solution
fits
the
problems,
we're
seeing,
etc.
E
E
If
it's,
if
it's
simple
things
like
adjusting
time
periods
like
saying
active,
is
shorter
or
longer
that
doesn't
really
change
the
infrastructure
much
it
just
changes
when
we
fire
the
ball.
But
if
it's
things
like
oh,
the
tagging
was
different
or
you
know
we're
now
putting
things
into
different
directories
based
on
and
I
think
at
one
point
somewhere
in
there.
A
A
I
think
that's
probably
a
good
outcome
from
this
meeting.
If
folks
are
happy
for
me
to
add
it
to
the
minutes,
we'll
say
at
this
point
in
time.
We
don't
think
this
model
should
be
considered
for
note
16
due
to
the
short
time
frame
in
which
we
have
like
just
six
weeks
and
that's
for
release
reasons
for
socializing
it
for
build
resource
like
for
a
number
of
reasons,.
A
A
A
E
A
C
You
know
pushing
major
breaks
every
week
like
it
seems
very
disturbing
from
a
consumer
point
of
view
and
yeah.
I
don't
know
if
we're
doing
our
part
with
that
regards
right,
we're
are
we
contributing
to
the
mass
that
the
world
is
getting
into
right.
Like
are
we
doing
the
right
social
thing
here?
Yeah.
A
A
Yeah,
I
certainly
agree
that
I
believe
this
proposal
may
encourage
or
force
different
behaviors
on
our
consumers
and
whether
those
behaviors
are
like.
Is
that
how
we
want
the
ecosystem
to
react?
Do
we
want
like
the
breaking
changes
to
happen
this
regularly
and
people
upgrade
more
often?
I
can
certainly
see
the
reasoning
behind
that,
because
we
always
want
to
encourage
people
to
upgrade
to
the
latest
for
bug,
fixes
and
security
reasons,
but
is:
is
this
too
far?
Is
it
pushing
them
too
much.
E
B
B
Like
I'm
constantly
having
to
explain
the
difference
between
even
like
an
odd
and
and
an
even
release,
I
don't
know
why,
for
some
reason
that
just
like
never
resonates
with
people
and
so
moving
it
to
something
that
isn't
even
putting
the
emphasis
on
the
semver
version.
I'm
a
little
bit
worried
about,
because
that
might
be
hard
for
people
to
digest
or
even
think
about,
and
then
they
might
just
get
stuck
on
versions
and
then
never
upgrade.
E
Okay,
no,
it
almost
sounds
flippant,
but
it's
almost
it's.
It's
almost
to
the
point.
That
december
only
makes
sense
for
the
sort
of
canary
current
bits
of
this
and
everything
else
you're
almost
at
the
stage
you're
saying
why
bother
having
to
send
them
version
in
there
at
all,
and
just
just
call
it
something
completely
different,
because.
C
E
D
A
Yeah,
I
I
kind
of
feel
like
making
the
call
that
we
had
that
note
about
node
16
and
following
the
proposal
and
figuring
out
problems
trying
to
figure
out
ways
of
gaining
feedback
on
these
things.
I
feel,
like
that's
kind
of
the
extent
that
we
can
get
to
today
and
we'll
see
how
it
evolves
between
this
meeting
and
next.
A
We
do
have
the
kind
of
process
documented
in
the
releases
md
file,
but
I
just
wanted
to
offer
if
anyone
wanted
to
like
pair
on
the
major
release,
with
a
view
of
maybe
doing
the
next
one
like
open
to
pairing
and
dedicating
some
time
or
doing
it.
As
a
group
like
if
folks
want
to
see
how
the
process
works.