►
From YouTube: CNB Office Hours: 2021/11/11
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
B
Sure
yeah,
I
just
put
this
on
here.
I
submitted
an
initial
pr
that
kind
of
adds
the
minimum
support
required
for
s-bom.
It's
really
just
bumping
the
api
versions
that
libcnb
supports
to
include
buildpack
api
0.7,
but
I
was
kind
of
wondering
people's
thoughts
on
how
far
we
should
go
in
libcnb
or
what
else
we
might
do
just
to
make
supporting
s
palms
easier.
B
B
I
think
my
opinion
is
that
it's
not
that
difficult
to
just
generate
that
information
as
a
build
pack
author
and
I'm
not
sure
that
libsyn
libcnb
really
needs
anything
else,
but
I'm
curious
what
other
people's
thoughts
were,
because
we
did
have
like
some
more
built-in
support
for
s-bomb,
with
the
older
format,
where
you
could
build
up
objects
in
memory
and
then
pass
those
to
lip
c
and
b,
and
it
would
just
write
them
out
magically
for
you.
So
I
don't
know
if
people
are
expecting
something
similar
for
for
the
new
support
or
not.
A
B
B
Yeah
yeah,
that
is,
and
it's
only
a
very
mild
convenience
to
have
a
writer
in
certain
cases
anyway.
So,
okay,
I
can.
I
can
submit
another
pr
for
something
kind
of
take
a
go
at
that
and
see
what
it
might
look
like.
It's
probably
just
a
matter
of
adding
a
function
somewhere
that
you
know
it's.
It's
pretty
simple
conversion,
maybe
some
cons
for
the
versions
that
we
support
for
the
formats
we
support
or
something
like
that.
Yeah.
A
B
Okay-
and
we
have
the
ones
we're
supporting
cyclone
dx,
spdx
and
sift.
B
Okay,
the
other
question
I
had
was
on
deprecation
of
the
older
format
of
s-bombs.
B
I
think
we
could,
you
know
very
easily,
just
deprecated
and
co.
You
know
code
comments.
Do
what
do
you
think
about
going
beyond
that,
though,
should
we
because
we
could
detect
when
someone
is
still
using
the
old
spot
format
and
either
log
a
debug
or
info
level
message
that
says
like
hey?
This
is
going
away,
update
your
build
pack.
C
It
won't
error.
It
will
warn
that
it's
not
really
supported.
C
A
Although
I
don't
know,
I
personally
have
a
stance
that
we
should
just
as
a
buildback
author.
You
should
just
error
out
so
that,
like
when
you're
doing
unit
testing
using
lip
candy,
that's
like
way
before
you've
actually
hit
an
actual,
build
and
running
it
on
some
production
cluster.
So
I
think
it
might
be
written
lip
c
and
b
to
error
out.
A
What
do
you
think,
like
the
life
cycle
may
still
just
give
a
warning?
The
lip
can
be
part
may
have
a
route
in
that
way
and
that
might
help
in
the
cicd
process.
Like
that,
hey
you
did
a
virgin
bomb,
but
the
format
you're
using
is
not
really
supported.
A
A
B
A
But
that
completely
makes
sense
from
the
projects
like
see
buildbacks
perspective.
That's
why
the
rfc
and
lifecycle
handle
that
for
you
so
like.
If
you're
still
on
the
older
api,
you
can
still
general
generate
those
bom
files
and
we'll
still
add
those
to
where
you
expect
it's
just
that
as
a
project.
We
expect,
if
you're,
moving
to
a
newer
api,
you
should
conform
to
that
api.
A
A
A
B
Yeah,
at
least
like
the
way
that
we
release
it.
It
seems
like
like
at
some
point.
We
have
to
bump
the
api
to
0.7
and
if
we
can't
retain
the
old
format
and
the
the
new
format
of
s-bomb
for
at
least
a
few
releases,
then
we're
left
doing
a
hard
cut
at
some
particular
version,
and
then
we
have
to
put
it
onto
the
users
to
say
like
when
you're
ready
to
upgrade.
C
I
don't
know,
I
don't
know
if
it's
worth
mentioning,
but
you
know,
even
though
it
does
worn,
it
doesn't
actually
process
the
old
format
when
you
bump
api
versions.
Does
that
make
sense,
maybe
not
very
intuitive,
but
basically
it
won't
do
anything
with
any
old
formatted
bomb
files.
Does
that
make
sense.
B
Okay,
so
that's
another
another
issue:
we're
gonna
have
to
work
work
through
because
that's
gonna
leave
us
again.
It's
like
a
hard
cut
over
okay.
A
A
C
I
mean
I
don't
have
strong
feelings,
I'm
not.
I
didn't
actually
have
a
say
in
this,
but
okay.
A
You
know
daniel,
do
you
mind
posting
that
again
in
the
implementation
chat?
So
maybe
you
can
pick
up
the
thread
there.
Yeah.
B
A
C
A
I
think
we
did
something
similar
for
some
features
and
it
at
least
I
remember
submitting
a
pull
request
where,
during
some
ap
version
boom,
something
was
unsupported
and
we
added
the
code
to
fail
instead
of
carry
on
so
so.
A
C
Maybe,
as
you
know,
the
life
cycle
is
sort
of
really
painful
to
sort
of
contribute
to,
because
of
basically,
we
support
basically
every
api
version
that
ever
is
made
and
every
time
you
make
a
change,
it's
you
know,
it's
very
you
know
it's
sort
of
hard
to
keep
all
the
logic
sane
and
make
sure
things
that
used
to
work
at
the
older
version,
still
work
and
things
work
for
newer
version,
and
you
know
there's
just
no
holistic
way
to
make
that
intact.
So
you
know
I've
been
thinking.
C
I
did
a
spike
personally
duplicating
all
the
files
every
time,
there's
a
new
api
version
and
while
that's
easy
to
follow,
it's
actually
very
ugly
when,
when
it's
all
said
and
done.
C
Oh,
no,
okay,
that's
a
good
question.
So
let's
say
that
sorry,
you
know,
let's
just
imagine
that
there's
a
code
that
handles
detect
like
a
detect.go
right
and
let's
say
in
a
newer
platform,
api
version,
there's
some
change
to
detection
right,
there's
some
changes
to
the
tech
code.
A
C
No,
that
that's
that's
fair.
Let
me
try
to
draw
it
out
like
maybe
we
could
have
like
detect
and
then
we
can
have
like
a
v2
dot
go
and
then
detect.
Let's
say
I
want
to
make
a
version
api
3.0.
I
do
that
I
did.
This
is
what
my
spike
basically
tried
to
do
right
like
every
time.
This
is
a
new
platform,
api
version,
just
sort
of
duplicate
the
file
and
then
add
the
change.
A
C
C
A
Okay,
so
for
each
new
version
of
the
life
cycle
supports,
there's
a
there's,
a
versioned
package
for
that
new
version
that
way
for
the
old
version
the
code
is
frozen
in
time
and
for
the
new
version.
You
have
new
code
and
then
it
dispatches
to
that
based
on
the
version
number.
C
Yeah,
I
mean
that's
what
I
tried
and
I
didn't
like
it.
I
was
wondering
if
you
know
we
all
had
to
try
something
in
a
similar
project.
You
know
all
the
practice
that
this
is
the
first
time
I've
ever
been
on
a
project
that,
like
you
know,
supports
previous
versions
and
and
never
like,
never
dedicates
them.
So
you
know,
I
guess
I
was
wondering
if
y'all
had
ways
around
this
or
something.
B
A
A
There
are
other
places
where
people
support
like
older
version
and
then
it
goes
based
on
semantic
version
versioning,
so
anything
that
zero
word
just
breaks
things
as
you
go
and
then
beyond
that,
once
you
hit
the
stable
api,
that's
supported
until
you
hit
a
new
major
version
and
if
people
update
to
a
major
version,
then
it's
on
them
is
this.
I
don't
think
there's
some
anything
as
complicated
like
backs
in
terms
of
compatibility
with.
We
have
lots
of
different
versions.
A
At
the
same
time,
kate's
api
versions
probably
come
close,
but
they
have
a
very
clear
versioning
strategy
and
they
also
had
a
clearly
laid
out
plan
on
how
to
get
people
to
upgrade.
A
C
Okay,
no,
it's
sorry!
I
was
just
you
know
wondering
if
something
came
to
mind,
what
do
you?
What
do
you
think
about
this?
This
is
just
the
spitballing
dumb
idea.
What
do
you
think
about
you
compile
multiple
versions
of
the
lifecycle
into
the
same
binary
and
then
at
runtime?
You
sort
of
you
know
pick
the
binary
you
want
based
on
the
platform
api
version,
I
mean
the
binary
would
get
kind
of
bloated,
but
presumably.
A
A
How
how
how
closely
related
is
the
platform
api
version
to
the
buildback
api
version
is
my
question:
would
are
there
certain
platform
versions
for
which
we
don't
support
certain
buildback
api
versions
like
how
would
the
versioning
strategy
go
in
your
case,
like
let's
say
we
add
a
new
buildback
version
08?
Would
you
go
back
and
add
it
to
platform
2
at
this
point.
C
Okay,
that's
a
good
question.
That's
not!
I
don't
think
that's
a
big
big
concern
right.
We
probably
wouldn't
do
that.
It
would
probably
be
in
a
newer
platform.
I
don't
think
the
bill
pack
versions
are
sort
of
too
much.
To
be
honest,
just
because
you
know
the
code
is
easy
to
manage,
like
the
code
isn't
spread
all
over
the
place
right,
but
you
know
when,
when
you
have
a
platform
change,
I
guess
that's
sort
of
the
problem
right.
The
platform
changes
aren't
really
localized.
It
could
happen
in
any
part
of
the
code
base.
C
C
That's
a
good,
you
know,
I'm!
A
In
my
opinion,
it's
easier
to
deprecate
platform
versions
right.
We
know
there
are
a
handful
of
platforms
as
opposed
to
buildbacks
like
if
a
new
version
of
pack
supports
a
certain
platform
and
like
we,
we
have
a
list
of
all
the
major
platforms
anywhere.
It's
either
packed
based
or
a
custom
solution
that
runs
the
life
cycle
directly.
C
B
Yeah,
I
think,
even
with
buildpack,
you
have
the
opportunity
to
start
injecting
messages
kind
of
into
the
stream
when
they're,
when
they
are
deprecated.
And
you
can,
you
have
an
easy
way
to
communicate
with
users
and
authors
so
that
you
can
at
least
give
some
notice
of
you
know
when
those
things
are
going
to
start
dropping
off,
but
I'm
definitely
in
favor
of
just
you
know,
pruning
off
some
of
those.
That
seems
like
the
easiest
approach.
B
A
C
Like
and
I
kind
of
think
it's
like
the
spec
right,
you
know
the
same
conversations
we're
having
around
the
spec
around.
Like
you
know,
I
kind
of
I
kind
of
see
it
as
the
same
same
issue.
It's
just
I
don't
know
for
some
reason.
We
have
more
more
fruitful
discussions
around
the
spec
on
branching
strategies
and
spectral
factors
and
stuff
like
that,
but
but
not
really
a
life
cycle
which
has
the
same
problems.