►
From YouTube: Working Group: 2020-11-17
Description
* Ruby Deprecation Dates
A
A
B
A
A
A
D
B
F
Yes,
there's
a
conversation
that
started
in
slack
about
filling
in
ruby,
deprecation
dates
and,
from
our
end,
I
think
it's
a
little
challenging
for
us,
because
ruby
does
not
publish
deprecation
dates
when
new
versions
come
out.
I
think
the
request
was
to
like
start
adding
them
as
ruby
announces,
deprecation
dates,
and
so
that
would
definitely
pose
a
bit
of
a
challenge
for
our
current
implementation
of
learning
about
new
dependencies.
F
I
was
kind
of
curious
what
your
thoughts
on
like
if
we
determined
this
would
be
too
difficult
to
do
what
what
mitigations
there
would
be
like.
Is
it
just
us
manually,
fixing
it
at
some
point
or
I'm
not
sure,
and
I'm
more
curious
if
there
are
any
other
options
other
than
us,
trying
to
constantly
check
to
see
if
they've
added
a
deprecation
date
at
an
arbitrary
time.
C
One
of
the
ones
that
does
not
have
a
deprecation
date
currently
listed
actually
does
have
an
announced
deprecation
date
from
the
review
like
core
team.
So
at
the
very
least,
I
think
that
one
should
be
like
updated
to
accurately
reflect
the
announce
date
for
the
other
two,
I'm
not
sure.
I
really
think
that
it
matters
if
we
have
an
estimate
of
what
the
future
is
or
we
have
nothing,
mostly
from
the
way
that
we
actually
would
present
this
to
users
is
within
30
days
of
that
date.
C
We
then
start
presenting
a
use,
a
user
with,
like
a
log
output
that
says
this
step.
This
dependency
is
about
to
be
removed
from
the
build
packer
reach
its
end
of
support
date.
You
should,
you
know,
consider
upgrading
to
a
newer
version
so
that
you're,
not
you
know
your
application,
isn't
broken
by
the
fact
that
this
dependent
dependency
is
getting
removed
so
for
those
ones
for
the
the
two
that
are
the
version
lines
that
are
newer.
C
Those
are
at
least
a
year
out
further
than
the
one
that
currently
does
have
a
deprecation
date.
So
for
us,
if
it
has
an
estimate-
or
it
has
nothing
right
now-
is
not
necessarily
all
that
important
because
of
the
fact
that
neither
one
of
those
is
going
to
show
any
sort
of
message
for
at
least
a
year
and
a
half,
and
so
we
have
a
considerable
amount
of
time
to
figure
out
what
the
strategy
should
be
there
for
those.
A
B
G
G
If
we
say
if
we're
just
guessing
that
this
is
when
it's
going
to
eol
and
we're
not
really
like
in
the
position
to
provide
users
with
that
guarantee-
and
I
I
would
agree
with
that
position-
I
don't
think
we
should
do
that
either.
So
I
think,
in
the
cases
where
there's
no
deprecation
date
listed,
that
should
just
be
empty.
A
Yeah-
and
I
think
you
should
be
able
to
you-
should
be
just
pulling
against
us.
You
know
once
a
day
once
a
week,
whatever
you
want
to
see
when
these
things
come
in
and
then
updating
the
record
in
the
core
depths
area
and
then
it'll
be
up
to
like
that,
should
not
trigger
a
rebuild
of
the
binary,
that's
associated
with
it.