►
From YouTube: 2021-06-17 Node.js Release Working Group Meeting
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
A
So
if
we
could
start
with
talking
about
the
minimum
icu
version
change
in
node
14,
I
don't
know
if
richard
you
can
happy
to
summarize
that
for
us.
B
Yeah
sure
so
there
was
a
comment
made
in
the
in
a
pr
regarding
updating
icu
to
icd6969,
saying
that
they
were
unable
to
build
node
1417.1
on,
I
forget
which
operating
system
now,
but
basically
they
were
building
against
the
system
icu
and
they
were
building
against
system
icu.
That
was
version
65.
B
And
I
had
a
look
at
so
for
icu.
There's
two
minimum
versions:
one's
in
v8
and
one
is
in
tools,
icu
or
talk
on
the
tools.
We
have
a
minimum
icu
version
and
it
looks
like
in
1400
we
went
out
with
a
minimum
icu
version
of
65
so
that
it
was
celeste,
so
slayers,
15,
they're,
building
against
system
icu
65,
which
for
node
1400,
was
met
the
minimum
icu
version.
B
It
looks
like
we
had
a
v8
update
in
1460,
which
bumped
the
icu
minimum
up
to
67.
So
that's
from
65
to
67.,
I'm
guessing
it
didn't
actually
break
the
build
because
no
one's
actually
complained
about
that.
Yet,
but
in
1471
with
the
icu
669
update,
that's
also
had
a
v8
patch
and
that
v8
patch
has
broken
compiling
v8
on
icu
65.
B
So
I
guess
the
question
in
the
pr
was:
what's
the
policy
and
breaking
compatibility
with
external
dependencies
during
the
lts
life
cycle,
and
I
kind
of
believe
that
we
don't
really
have
a
written
policy
for
that.
But
it's
probably
that
we'd
like
to
avoid
it
and
the
question
is:
what
does
what
do
we
do?
B
B
What
do
we
think
we
should
do
with
node
14,
given
that
we've
already
bumped
the
minimum
up
once
since
we
ga'ed
14
and
the
current
minimum
version.
B
I
I
don't
know
for
certain
that
that's
I
haven't
tried
to
build
1471
with
icu
67.
We
didn't
bump
it
up
with
the
v8
patch
that
went
in
last
time,
but
yeah.
I
I
don't
know
what
what
sort
of
other
thought
you
know.
A
B
A
I
think
when
things
have
like
this
have
happened
before
we've
just
addressed
them
on
a
case-by-case
basis,
so
I
guess
trying
to
figure
out
what
the
right
call
is
to
do
here
is
reverting
the
change
to
the
minimum
possible
without
completely
reverting
like
massive
chunks
of
v8.
Do
you
know
if
that's
possible.
B
I
I
don't
know
right
this
moment
so
at
least
for
1471
it
looked
like
it
was
just
one
v8
patch,
but
that
v8
patch
was
supposedly
because
icu,
68
or
69
has
dropped,
dropped
an
internal
api
that
v8
was
using,
so
I'm
without
really
looking
at
it.
I
suspect
it
probably
is
possible
to
patch
that,
because
I
think
it's
a
v8
internal,
so
it
shouldn't
be
it
shouldn't
sort
of
be
visible
to
the
outside.
C
I
don't
know
exactly
what
we
can
do,
what
are
well,
all
the
options
are,
but
one
obvious
option
would
be
to
revert
the
ico
update
and
the
related
v8
patch.
B
C
Yeah,
the
minimum
ico
version
on
our
side.
It's
just
a
field
in
a
json
file.
I
think
it's
here
to
to
just
to
tell
us
that
that
some
breaking
change
are
coming.
B
C
V8
updates-
and
I
know
that
I
have
to
bump
it
because
it
it
doesn't
build
if,
if
the
minimum
version
on
our
side
is
different
from
the
minimum
version
on
the
v8
side
yeah,
we
have
an
explicit
test
for
that
as
well.
C
B
C
B
Yeah
I'll
I'll
I'll
take
a
look
but
yeah.
It
definitely
sounds
like
we
probably
don't
really
want
to
intentionally
prevent
things
that
were
building
from
building
in
a
especially
since
17
one
was
a
patch
release.
It
wasn't
even
a
minor.
B
C
Okay-
but
we
can
still
continue
talking
about
this,
because
the
next
v8
update,
which
is
9.2,
also
bumps
the
minimum
icu
version-
oh
okay,
and
so
the
question
is
now:
what
do
we
do?
With
version
16.
B
B
I
I'd
have
to
go
and
check
but
yeah
whatever
the
minimum
is
and
then
whether
whether
the
the
next
v8
version
that
really
is
a
minimum
or
that's
just
them
conservatively
bumping
the
version
to
match
the
version.
That's
in
the
ice,
the
v8.
C
I
I
referenced
so
I
did
a
separate
commit
bumping,
the
ico
version
and
inside
there's
a
reference
to
the
v8
commit
that
did
it
and
they
changed
some
code
where
they
use
icu
right.
Okay,
maybe
we
can
just
revert
that
and
and
yeah.
B
I
I
guess
for
v8,
in
order
for
v8
to
land
a
v8
okay,
in
order
for
9.2
to
land
on
16,
I'm
I'm
guessing
we'd
have
to
scan
it
for
any
api
breakages
anyway,
because
I
saw
from
the
9-1
update
for
note
16,
you
went
through
a
slightly
different
process
to
to
sort
of
go
through
the
commits
and
check
them
for
compatibility.
So
it's
not
going
to
be
a
straight
dump
of
v8
92
into
16.
Is
it.
C
B
B
If
we
say
revert,
revert
something
related
to
icu
and
v8
that
we
would
have
any
confidence
that
that
hasn't
broken
something
locale
specific
or
you
know
in
one
of
those
internationalization
apis,
because
I
don't
think
the
existing
internet
into
into
intel
tests
or
node
14
caught
the
thing
that
we
can
currently
have
a
v8
back
port
open
for
that
doesn't
seem
to
fail
any
of
the
existing
intel
tests.
B
So
yeah,
I'm
not.
B
Yeah,
I
guess
we
might-
we
could
also
reach
out
to
the
I
don't
know
how
active
they
are
now,
but
the
the
the
I
I
18n
api
team
in
node
to
see
if
they've
got
any
any
views
on,
should
fixing
an
icu
version
versus
continually
upgrading.
It.
A
A
B
That's
correct,
but
I
I
think
we
can
update
the
time
zone
data
separately.
I
think
we
haven't
done.
B
Okay,
I
I
guess,
unless
anyone
else
has
anything
else,
to
bring,
we
just
sort
of
continue
discussing
that
I
guess
we
could
either
create
another
issue
or
in
the
exit.
You
know
in
an
existing
issue
somewhere.
A
Yeah,
maybe
maybe
yeah
creating
an
issue,
just
the
concept
of
updating
them
in
release
lines,
and
then
we
can
bring
in
the
folks
from
the
internationalization
groups
that
may
have
other
opinions
all
right,
I'll
open
an
issue
after
the
after
meeting
yep.
It
sounds
good
for
the
plan
for
this
one
to
try
and
see
if
we
can
patch
it
work
around
it
and
if
not
open
a
reverb.
A
C
A
Okay,
so
for
node
16
we
are
scheduled
up
until
the
end
of
the
month
and
then
we
have
some
gaps
after
that,
but
I
think
that's
probably
fine.
As
long
as
we're
scheduled
a
few
weeks
in
advance.
That's
good!
D
Is
it
yeah
hopefully
today,
but
I
think
npm
goes
out
like
midday
for
me,
so
I
just
don't
know
if
I'm
gonna
be
able
to
get
the
build
and
approvals
by
like
pull
that
that
change
in
so
honestly,
it'll
probably
be
tomorrow.
A
Would
would
tuesday,
like
delay
deferring
to
next
tuesday
be
preferable
in
that
case,
I
just.
D
Friday,
yeah,
I
can
do
any
any
day.
I
guess
just
in
terms
of
like
what
expectations
are,
so
I
don't
know
like
if
the
if
tuesday
is
like
an
arbitrary
day
or
if
there's
some
kind
of
like
service
level
agreement
that
says.
Oh,
we
should
get
it
out
as
close
to
the
release
date
as
possible,
so
yeah,
but
I'm
good
it's.
I
can
do
whatever.
A
Yeah,
I
think
I
think,
generally,
like
tuesday
is
kind
of
arbitrary,
but
it
does
align
with
quite
a
few
folks
going
for
patch
tuesdays.
That's
just
tends
to
be
what
we
schedule
it
for
we
do
say
it
can
always
be
flexible.
I
think
the
one
thing
we've
traditionally
tried
to
avoid
is
friday
releases
because
of
like
consideration
for
dumping
releases
on
people
who
have
to
manage
the
upgrades
like
just
before
the
weekend.
So
that's
the
same
suggestion
about
delaying
it
next
week
and
okay
we're
doing
a
friday
release.
D
I
think
that
makes
sense
just
for
anything
anyone
that's
using
a
build
or
a
node
for
build
and
they
maybe
haven't
locked
their
node
version,
and
you
know
if
a
new
version
comes
through,
then
that
might
break
some
builds
without
them.
Knowing
so,
I
think,
that's,
probably
a
good
policy.
D
A
D
Okay
and
then
I
guess
so,
maybe
we
could
talk
about
it
really
quickly
right
now,
then
do
we
think
that
I
guess,
since
we
already
have
have
a
16x
coming
in
now
12
days
and
there's
I'm,
do
we
even
want
to
wait
for
that
npm
release,
or
should
I
just
go
through
with
it,
and
should
I
just
take
all
the
npm
stuff
out
now
and
then
those
changes
can
go
in
in
the
next
60
next
release?
That's
the
other
option
is
that
I
just
do
the.
A
Yeah,
I
think
I
think
that
would
make
sense
in
this
case,
like
backing
out
the
problematic
commits
from
the
proposal
and
then
shipping
what
we
have,
and
then
that
gives
time
for
say
the
new
mpm
update
lambs
today
on
the
main
branch
it
gives
time
for
that
to
kind
of
bake
like
an
extra
10
or
so
days,
yeah.
B
A
D
A
For
me,
yeah
that
sounds
good
and
then
I
don't
think
it's
a
problem
having
just
like
the
slightly
shorter
12
days
between
releases.
I
think
we
can
keep
schedule
resist
that
way.
Okay,.
A
So
that
was
our
schedule
for
node
16
and
then
for
node
14.
Where
are
we
at
well,
we
had
the
1417
one
release
this
month.
How
urgently
do
we
think
we
would
need
to
get
that
river
out.
A
A
A
A
critical
bug-
and
they
can't
upgrade.
C
This
icu
issue
is
with
someone
who,
who
does
the
custom
build
of
node
right.
B
So,
typically,
linux
packages
build
node
against
shared
libraries
rather
than
the
same
way
we
built
the
releases,
the
binary
releases-
I
don't
know
I'd-
have
to
go
check.
I
I
have
seen
this
known
before,
so
I
I
think
he
might
actually
be
a
package
of
a
linux
package
for
bustlers.
A
B
If
it
was
a
revert,
it
would
probably
just
be
a
release
to
just
revert
that
commit,
I
think,
if,
if
it
was
deemed
but
yeah.
B
Right
word,
but
sort
of
you
know
sooner
rather
than
later.
I
wouldn't
want
to
bundle
it
up
with
too
many
other
commits.
A
A
Okay,
I
guess,
after
after
you've
investigated
and
determined
that
a
lot
like
correct
approach
and
we've
also
opened
that
issue,
then
maybe
maybe
then
we
can
better
make
the
call
whether
it
needs
something
urgent
more
urgently,
rather
than
waiting
a
couple
of
weeks
or
so
until
we
have
availability.
A
C
A
A
C
No,
it's
not
modules
related,
but
maybe
there
are
things
still
for
modules.
I
don't
know.
A
I
have
to
dig
it
out.
I
remember
seeing
something
someone
saying
hey
back
this
out
of
the
1416
and
pour
it
into
a
later
release.
A
Okay
sounds
good,
so
it's
just
july
patch
release,
but
we're
trying
to
figure
out
the
timings
after
we've
seen
the
results
of
our
icu
investigations.
B
I've
arbitrarily
picked
a
date,
so
it
doesn't
have
to
be
right.
Then
you
know
we
can
push
it
out
a
bit,
but
I'd
like
to
schedule
a
12
release.
There
is
a
bit
of
stuff
building
up
on
the
staging
branch
now
and
there
was
another
pr
I
saw
that
I
think
anna
put
in
that
was
a
fix
for
dark
bindings
or
something
for
embedders,
so
that
that
could
also
land
on
the
12th
staging
branch.
So
yeah,
it's
been
a
been
a
while.
B
We
haven't
had
a
12
release
since
april,
and
that
was
a
security
release.
So
just
a
sort
of
smallish.
I
think
I
don't
think
there's
much,
but
there's
probably
enough
stuff
to
do
with
small
release.
A
Sounds
good
yeah
as
long
as
we've
got
availability
and
there's
some
bits
on
the
branch.
I
don't
see
why
not,
after
a
couple
of
months,
shipping
a
release
seems
seems
reasonable
seems
like
good
timing,
so
yeah
thanks
richard
and
then
I
guess
after
that
we
just
kind
of,
as
we
have
played
by
here,
seeing
what's
on
the
open
back
ports
and
stuff
to
make
the
call
for
future
release.
A
A
Nope;
okay,
with
that
I'll
leave
it
at
that
and
speak
to
you
all
later,
thanks
for
joining
everyone.