►
From YouTube: Working Group: 2020-05-14
Description
* Pre-1.0 API Compatibility
* Publish Buildpack RFC: https://github.com/buildpacks/rfcs/pull/75
* Working Group YouTube publication
* Layer Metadata RFC: https://github.com/buildpacks/rfcs/pull/63
B
C
A
D
Just
put
this
up
an
hour
ago,
so
it's
don't
expect
anyone
to
have
read
through
it.
Already
I
was
working
on
a
larger
spec
compatibility
version
RFC.
That
would
also
describe
how
we
can
migrate
to
100,
but
I
started
to
carve
out
just
the
smaller
portion
of
this
to
make
them
more
limited
RFC.
So
what
it
proposes
is
that
pre
100
API
versions,
you
can
assume
compatibility
with
future
ones
that
come
out.
So
it's
just
about
lifecycle,
compatibility
rules.
D
It
doesn't
even
necessitate
that
the
spec
itself
can't
remove
features
but
linkless,
but
I
can't
add
things
that
are
entirely
incompatible
with
another
Oh
X
API
version,
and
that
the
life
cycle
will
maintain
support
for
the
older
versions,
even
as
it
implements
new
ones.
I
think
this
should
unblock
us
from
making
a
lot
of
adding
a
lot
of
new
features
that
have
been
hung
up
on
trying
to
figure
out
how
to
do
that
without
paying
for
bill
petkin
platform
authors.
So
everyone
read
that
and
approve
it.
If
you
feel
so
inclined.
E
My
request
to
the
leadership
team
and
the
interested
parties
from
the
platforms.
Please
can
we
expedite
this
one?
It
is
definitely
holding
up
a
bunch
of
other
RFC's
or
not
even
sorting
out
our
sees
a
bunch
of
things
that
have
passed
our
RFC
and
can't
make
it
into
lifecycle.
Implementations
right
now,.
D
Something
like
build
packs
we
approved
in
RFC,
where
bill
packs
can
add
labels
to
the
exported
image
and
technically
that
is
exchanged
to
the
specs.
So
it
should
come
out
with
a
change
to
the
API
version,
especially
if
field
packs
require
that
feature,
so
they
can
indicate
that
they
require
it,
but
because
the
next
API
version
is
assumed
to
be
non-breaking
by
our
original
rules.
E
It
would
also
help
us,
there's
long,
been
a
list
of
like
a
set
of
braking
API
changes
that
we
want
to
make
before
we
hit
100
that
one.
Oh,
it
looks
better
than
it
does
today
and
everybody's
afraid
to
make
those,
because
you
either
have
to
do
them
all
in
one
Big
Bang,
so
it
doesn't
kill
the
platform
vendors
or
you
just
don't
do
them,
and
you
do
a
bunch
of
incompatible
minor
or
incompatible
miners
that
that
kill
the
platform.
E
B
B
F
Let's
give
an
overview
of.
It
is
basically
what
he
Xavier
came
up
with
was,
in
addition,
destroying
the
URL
and
to
the
registry
and
the
pack
config
also
storing
a
type.
So
the
two
types
we
would
support
initially
are
github
and
get,
and
then
the
published
command
and
probably
some
other
commands
would
behave
differently
based
on
that
type.
F
And
then
the
reg
of
those
registries
would
have
like
an
ID
or
a
name,
and
you
would
reference
them
based
on
that
that
ID,
that
name
so
actually
actually
kind
of
similar
to
what
I
was
proposing.
Last
time,
where
you
would
pass
like
different
flags
to
the
published
command,
but
instead
of
passing
flags
to
the
published
command,
we're
sort
of
tightly
coupling
the
type
to
the
actual
registry
in
its
URL.
F
F
Yeah
one
of
the
drawbacks
here
is
that
this
may
be
even
going
to
draw
back
before.
Is
that
the
type
can't
really
be
a
content
for
well
and
build
pack,
you
will
I
think
define
which
was
colon,
slash,
slash,
I,
think
there
are
created
some
options.
There,
though,
like
I'm,
not
really
even
sure
what
URL
would
have
looked
like
before
like
would
it
have
been
bill,
packs
that
I
Oh
is
the
host
or
or
would
it
have
been
github
as
though
so
I'm
not
sure?
That's
actually.
F
Yeah
and
some
alternatives
like
inferring
the
type
rather
than
making
it
explicit,
so
we
could
say:
oh
it's,
a
github,
calm,
host,
yeah
I,
assume
that's
a
github.
It's
a
local
file
path,
I
assume!
That's
a
local
git
repo
yeah.
So
take
a
look
at
those
we
can
discuss
today,
but
I'd
also
like
to
get
to
the
other
things.
B
B
E
We
had
discussed
that
once
we
started
recording
the
sessions
and
it
appears
to
have
worked
to
the
best
of
our
ability
that
recording
started
automatically.
The
people
on
new
enough
versions
of
zoom
were
given
the
disclaimer,
which
is
really
the
best.
We
can
do
that
we
were
actually
going
to
publish
them
the
way
other
CNCs
projects
do
any
strong
objection
to
us
doing
that
now
and
do
we
have
an
official
CNB
Google
account,
but
for
YouTube
that
will
allow
me
to
publish
under
some
useful
name,
I.
A
A
C
Hi-Yah
I
wrote
that
I
tried
to
sum
up
what
I
was
getting
at
in
the
title
of
the
PR
and
at
the
time
that
I
had
reading
this
and
I
assume
that
it's
still
true,
if
you
can,
you
can
docker
inspect
an
image
that
was
created
with
both
backs,
and
it
has
a
all
the
metadata
of
the
launch
layers
in
the
docker,
inspect
output
and
I
thought.
It
would
be
useful
for
me
if
we
also,
but
if
I
could
also
see
the
layer
metadata
for
non
launch
layers
because
I'm
at
my
party
this
this.
C
This
goes
along
with
my
particular
use
case,
which
is
kind
of
wanting
to
know,
like
all
the
factors
that
were
at
play
during
that
images
build.
So,
of
course,
I
want
to
know
what
version
of
a
build
pack
I
was
using,
but
I
also
in
my
case,
to
be
already
concrete.
I
want
to
know
the
SHA
the
get
shot
of
the
application,
repo
that
the
build
pack
saw
when
it
when
it
executed
against
that
application.
C
I
commented
about
that
a
lot
in
the
RFC,
like
my
particular
use
case,
but
this
I
wasn't
asking
for.
Like
first-class
support
for
that
necessarily
because
I
thought
would
be
good
enough.
Well,
if,
if
we
just
get
all
the
lot,
all
the
layer
metadata
in
the
in
the
image
label
somewhere,
then
I
can
put
whatever
I
want
in
the
metadata
and
it'll
be
there
for
me
and
the
the
bigger
context
around.
E
There
a
reason
that
putting
a
allowing
or
having
a
build
pack
that
puts
all
of
that
information
into
the
outgoing
build
pack
plan.
So
it's
attached
to
the
Bill
of
Materials
isn't
sufficient,
because
the
Bill
of
Materials
also
includes
what
build
pack
and
ID.
In
version
a
bill
of
materials.
Entry
came
from
I.
C
E
Reason
I
asked
that
is
over
in
the
picado
build
packs
group.
We
actually
do.
This,
like
I,
was
unaware
that
this
wasn't
already
happening,
because
we
have
a
bunch
of
build,
only
build
packs,
it
actually
put
stuff
in
the
bomb
and
so
I
regularly
just
confused,
what's
in
the
bill
of
materials
versus
what's
in
the
image,
metal,
plate
or
metadata
label,
and
it
turns
out
that
I
had
thought
this
wasn't
a
problem
because
we
see
all
of
this
in
the
bill
of
materials.
E
It's
certainly
not
a
requirement
right,
like
the
big
difference
is
it
does
require
a
build
pack
to
explicitly
behave
in
this
way,
rather
than
just
attaching
layer
metadata,
but
in
some
ways,
I
also
think
that
that's
a
good
idea
right.
We
expect
the
bill
of
materials
to
be
much
more
user
facing
than
layer
metadata,
specifically
as
layer
metadata
is
useful
for
the
build
pad
to
talk
to
itself
in
the
future,
in
a
way
that
the
build
materials
is
something
that
you
might
want
to
expose
to
a
user.
F
A
E
D
The
two
things
number
one
I
think
I
might
have
scared
people
off
commenting
on
this
PR
by
complaining
about
the
itch
on
the
metadata
example.
But
I
ran
into
a
situation
the
other
day,
where
I
actually
really
wanted
that
so
I'm
duly
sheepish
about
that
and
would
like
to
retract
it,
but
to
Ben's
point
about
the
Bill
of
Materials
I.
D
Do
think
the
one
limitation
there
that
makes
this
appealing
in
addition
to
having
the
Bill
of
Materials
is
that
when
I'm
looking
at
the
Bill
of
Materials
I
do
want
it
to
describe
what
exactly
is
in
the
image
so
tools
that
only
existed
at
Build
time.
I
would
necessarily
want
that
to
be
to
confuse
me
to
think
that's
in
the
Bill
of
Materials
I
could
see
it
as
like
metadata
on
a
different
entry
in
the
build
materials
that
provides
context.
So
I
think
we'd
have
to
be
careful
about
how
we
added
it
there.
F
E
Agree
but
I'm
not
sure
well,
I,
guess
it
depends
on
what
you
think
a
bill
of
materials
is
right.
A
bill
of
materials
is
a
list
of
what
inputs
outputs,
just
arbitrary
metadata
associated
with
it.
There
is
I
think
we
think
about
the
Bill
of
Materials
as
something
describing
exactly
what's
inside
of
a
image,
but
I
don't
think
that
is
definitive.
E
B
E
D
You
think
calling
it
build
materials
and
having
things
that
aren't
actually
in
the
images
can
be
using
them
like
if
I
compiled
an
application,
but
my
application
with
maven
I'd
want
to
see
and
entering
the
build
materials
that
describes
an
application
and
then
maybe
in
the
metadata
for
that
entry.
It
could
give
me
information
like
what
version
of
maven
I
used
to
require
it,
but
I'm
not
sure
if
it
should
be
listed
as
a
top-level
thing.
D
B
Like
backing
up
a
little
bit
coming
back
original
RFC
requesting
that
the
build
layer
information
get
put
in
there,
the
Bill
of
Materials
is
like
a
high-level
description
of
you
know
not
thinking
about
that
layers
that
comprise
the
image,
but
thinking
about
the
semantic
things
that
are
going
into
it.
No
js'
right
that
kind
of
thing:
for
end-users
to
be
able
to
say,
okay,
I
had
got
a
note
up
here
and
it's
built
using
these
modules,
and
you
know
it's
a
high-level
description.
That's
not
supposed
to
describe
exact.
B
You
know
layout
of
the
bits
of
the
image,
whereas
the
layer
of
metadata
describes.
These
are
the
layers.
Here's
information
about
each
layer
right,
the
including
information
about
the
build
layers
that
were
used
at
build
time
to
build
the
image
seems
useful
because
it
tells
you
you
know
these
are
the
constituent
pieces
that
were
created
in
order
to
generate
this
thing
at
a
lower
level.
B
There
was
also
another
thing
that
was
I:
think
I
brought
up
the
build
materials
as
an
option
to
solve
the
same
problem
earlier,
and
the
answer
I
think
Paul
you
provided
was
something
about
being
able
to
understand,
because
we
had
this
caching
mechanism
right.
The
build
layers
can
come
back
in
subsequent
builds
being
able
to
understand
exactly
which
build
layer
was
generated.
If
that
makes
sense
the
you
that
was
used
to
build
this
particular
image.
C
E
We
yeah
so
do.
We
think,
then,
that
the
image
layer
metadata
is
a
publicly
contracted
API.
That
external
party
should
be
able
to
depend
on,
like
I
think
that
the
Bill
of
Materials
definitely
is
that,
but
I
have
often
thought
of
that
layer
metadata
as
only
contractually
guaranteed
between
a
build
pack
and
that
same
build
pack
at
some
point
in
the
future.
F
I'm
not
sure
the
bomb
is
like
we
sort
of
expose
it
that
way
as
like
a
public
API
but
I'm,
not
sure,
there's
enough
trust
in
it
that
people
that,
like
prod
suck,
isn't
all
so
good
just
gonna,
do
image
scanning
and
have
more
faith
than
that
so
like
in
some
sense,
I'm,
not
sure
the
contract,
like
the
outward
contract,
is
as
strong
as
we
would
like
it
to
be.
So
it's.
E
Not
yeah,
it's
not
so
much
what
people,
whether
people
outside
trust
it
it's
whether
we
are
making
compatibility
guarantees
about
it
from
our
side
right,
like
the
lifecycle,
it's
not
documented
yet,
but
I
know.
Emily
is
working
on
her
platform.
Spec
rewrite
where
the
actual
schema
of
the
of
the
metadata
label
of
the
bill
materials
label
effectively
will
be
specified
right.
It
will
be
a
breaking
change.
If
we
change
things
in
it,
you
can
as
a
build
pack
author
decide
well.
E
This
is
a
because
that
is
something
that
is
specified
and
people
know
that
it
can
will
never
change
when
I
put
something
in
there
and
I
put
it
in
at
a
particular
key.
I
now
consider
this
contractual
versus
layer
metadata.
If
that
structure
gets
specified.
Now,
all
of
a
sudden
I
want
to
change.
You
know
I
put
I
go
into
my
my
go
annotation
for
some
backticks,
and
so
it
you
know,
says
Tom
Tom,
a
comma
or
comma
colon,
and
it
makes
everything
lowercase
instead
of
the
uppercase.
E
E
B
Think
part
of
what
Paul
is
looking
for
isn't
just
this.
You
know
kind
of
freeform
stuff
that
put
in
the
layer
tamil
file,
it's
a
contractor
to
build
pack
itself,
but
just
information
about
job
the
layer
that
was
used
right
so
that
you
can
trace
that
back
and
figure
out
which
know
is
the
solder?
Is
this
newer?
So
I
don't
know
if
the
RFC
implies
necessarily
that
it's
externalizing
that
part
of
the
contract,
the
metadata
part
of
the
contract.
D
D
D
Don't
feel
like
this
is
changing
anything,
that's,
maybe
less
than
ideal
about
the
contract
of
the
layer
metadata
in
some
ways,
because
we're
already
quitting
layer
metadata
on
a
label
on
the
image-
and
this
is
just
adding
more
layers
to
the
set
of
those
that
are
included
in
that
metadata.
So
I
think
whatever
problems
we
might
have
there
or
discussions
about
how
we
specify
it
or
not.
This
doesn't
make
those
better
or
worse,
particularly.
E
I
can
agree
with
that,
but
I
think
there's
an
implication,
though,
if
we
actually
do
this
like
this
goes
through
the
RFC
process
and
comes
out
the
other
end,
we
are
effectively
specifying
it,
maybe
actually
specifying
it,
and
it
ties
the
hands
of
the
lifecycle
in
the
future.
The
lifecycle
can
no
longer
make
this
change
or
like
can
no
longer
change
the
structure
of
that
at
will.
E
Where
I
think
today
it
is
because
you
could
depend
on
it,
but
the
fact
that
that
structure
has
never
been
documented
anywhere
is
like
a
clear
sign
that
the
life
cycle
continues
to
be
an
internal
implementation.
Detail
that
you
should
not
look
at,
and
that
means
the
life
cycle
has
all
the
prerogative
in
the
world
to
completely
change.
It
can
change
it
from
tamil
Jason
yamo
anything.
It
wants
right
at
CSV,
limited
file,
and
if
we
accept
this,
the
life
cycle
no
longer
has
that
privilege
and.
B
Arguably,
we've
been
putting
this
metadata
same
format
and
every
image
that's
been
produced
by
cloud
native,
build
packs,
for
you
know
several
years,
if
I
think
we're
past
the
you
know,
if
we
labeled
it
IO
build
packs,
don't
touch
this
or
something.
Maybe
that
would
be
a
you
know,
one
thing,
but
because
we
we
didn't
take
the
opportunity
to
explicitly
declare
it,
as
this
is
now
part
of
the
public,
API
I,
don't
know
how
much
the
semantics
of
the
decision
fall
out
into
practical
outcomes.
This.
G
D
A
A
B
Excellent
point
is
this
kills
reproducibility.
In
many
cases
we
put
build
layer
metadata
in
there.
We
are
gonna
generate
the
same
and
during
the
same
image
twice
and
have
the
digest
of
the
content.
Blob
be
different
and
therefore
the
digest
manifest
be
different
and
we've
broken
reproducibility
for
no
potentially
lots
of
users.
They're.
D
Confusing
thing
about
it
is
we
store
metadata
to
disk
before
the
build
runs,
and
if
it's
not
a
launch
player,
it's
a
cash-only
layer.
The
Benedetta
we
restored
a
disk
is
going
to
be
the
metadata
that
comes
out
of
the
cache,
because
that
describes
the
layer
we
have
available
to
us.
Even
if
it
wasn't
the
layer,
it
does
use
to
build
a
previous
image,
and
you
worry
if
people
will
look
at
that
and
assume
that
the
meta
today
they're
getting
is
gonna,
be
the
one
on
the
image.
D
E
Do
want
to
say
Paul
like
we
absolutely
observe
that
the
use
case
that
you
want
to
satisfy
is
a
critical
one.
That's
the
reason
why
we've
actually
done
their
RFC's
floating
around
I,
don't
know
exactly
what
state
they're
in,
for
example,
communicate
source
control
information
through
the
system.
It's
it
is
in
fact
special
case
service
control
information,
because
it
is
so
critical
and
I
do
think
that
including
information
about
the
build
is
a
good
thing
that
we
need
to
do
I.
My
concern
is
just
about
attaching
it
to
the
image
in
this
particular
way.
B
It
seems
like
our
poor
Tamil
is
a
really
good
way
to
achieve
this
goal
right.
It
gives
because
everybody
what
they
want.
Is
there
a
reason
Paul
day
you'd
want
that
meditated
to
be
on
the
image
supposed
to
be
a
different,
build
output.
Next
to
the
image
that
you
know,
you
could
attach
back
to
it.
If
you
wanted
to
somehow.
C
C
B
C
E
Do
we,
what
do
we
see
report
for
you,
platform
owners
out
there
Matt
KPAC
and
her
aqui
team
and
everybody
else?
What
what
do
you
think
he'll
do
with
report
Tamil?
Is
that
something
that'll
be
like
shoved
in
as
an
injury
in
the
registry
next
to
the
image
manifest?
Is
it
something
that
only
exists
in
a
you
know
my
sequel
database
in
your
platform
to
be
shown
via
a
UI?
What
is
it,
what
are
you
gonna
do.
A
That's
CD
for
a
few
hours
if
I
might
use
case,
the
primary
original
use
case
report
Tom.
Well,
let's
just
just
read
it
after
export,
so
we
need
the
exact
digest
that
was
produced
by
the
build,
but
platforms
like
pack
could
also
somehow
expose
additional
metadata
about
it.
So
really
all
we
wanted
was
just
the
digest
key.
E
G
Yeah
I
mean
I,
guess
it
partly
depends
on
what
goes
in
report
tunnel
way
to
keep
it
expands
to
include
some
of
the
other
information.
I.
Think
users
would
use
it
more
or
want
to
have
that
information
like
if
it
solves
calls
use
case
like
I.
Don't
think
Paul's
unique
in
that
if
someone
coming
to
Heroku
is
building
a
thing
they
want
to,
if
for
dividing
purposes,
want
to
be
able
to
see
the
information
pretty
easily.
E
E
B
If
we
have
a
almost
bigger
problem,
you
know
this
reproducibility
thing
and
getting
build
time
versus
run
time.
Information
on
images
right
now,
if
you
use
the
build
plan,
you
know
to
request,
like
we
have
the
chaos
idea
of
a
yarn
installed,
buildpack
the
request
yarn
from
a
build
pack
just
installed
yarn
right
for
modularity.
B
If
you
request
that
as
a
build
time
only
dependency
you're
gonna
get
that
in
your
build
materials
with
the
yarn
version,
the
arm
version
changes
its
gonna
break
reproducibility
on
your
image,
I
wonder
if
we're
putting
too
much
of
the
delay.
If
the
idea
of
launched
and
build
being
special
in
the
build
plant
comes
back
and
we're,
we
need
to
exclude
more
information
from
the
images
we
generate
in
order
to
hit
that
reproducibility
goal
effectively.
E
E
The
adult
materials
would
be
empty
by
default
and
all
of
these
things,
if
we
didn't
choose
to
do
it
so
I,
don't
think
that
we
have
a
policy,
have
a
structural
problem
in
this
pack,
but
maybe
the
fact
that
we
don't
have
a
way
of
describing
build
and
launch
dependencies,
or
something
like
that
has
encouraged
us
to
put
too
much
in
the
bomb.
Then
we
otherwise
might
have
needed
to
work
should
have
the
bill.
B
Of
materials
as
a
sorry,
the
build
plan
as
a
mechanism
that
build
pack
communication
around
double
time
dependencies,
it's
very
useful
and
is
used
that
way,
a
lot
right
and
so
tying
that
in
the
spec
to
the
build
materials
as
an
output.
Right
like
it's,
a
huge
foot
gun
at
best
right,
yeah
I
mean
it
does.
E
G
Guess
I
just
like
with
Stephens
points
just
like
setting
people
up
for
success
by
default
of
just
like,
like
a
vacate
you
if
you're
like
learning
this
on
the
fly.
You're
like
you're
gonna,
use
this
thing,
and
you
may
not
realize
that
you're
putting
a
bunch
of
stuff
nicely
in
the
build
materials
by
default.
Yeah,
whereas
a
flag
makes
it
a
little
more
clear
that
you
are.
B
Forests
on
the
potato
team,
as
an
RFC
he's
working
on
that
ads
kind
of
further
contracture
Eliza's
the
build
plan
in
some
ways
that
I've
you
know
come
up
I
think
been
incorporates
a
lot
of
your
feedback
from
from
the
last
kind
of
set
of
proposed
changes.
One
of
those
is
a
set
of
capabilities
around
launch
and
builds,
and
so
when,
when
that
comes
up,
we
couldn't
bring
this
up
again
and
figure
out.
If,
if
that
will
help
solve
some
of
these
problems
because
I
suspect
it
will
yeah.
E
So,
let's,
let's
circle
this
to
close
down
this
discussion:
let's
circle
it
back
to
Pauls
actual
PR
here
this
is
RFC.
What
what
do
we
want
to
see
out
of
this?
A
an
update
to
the
RFC
that
takes
report
normal
into
account
or
like
what?
If
what
do
we
think
is
a
actionable
outcome
of
this
discussion
vote.
A
C
B
Awesome
I
think
that
was
last
item
on
the
agenda.
Is
there
anything
else
anybody
wants
to
chat
about
I,
really
appreciate
you
showing
up
Paul
you're,
always
welcome.
We
really,
like
you,
know
any
external
contributions
we
get
from
people
who
don't
show
up
regularly.
So
please
turn
into
a
regular
contributor.
If
you're
interested
really
appreciate
your
presence
here,.
C
G
A
G
E
B
You,
the
Wednesday
meetings,
tend
to
have,
you
know,
sometimes,
third,
more
sometimes
twice,
as
many
people
show
up.
Those
are
the
larger
ones
that
Thursday
ones
are
the
you
know,
people
who
really
tend
to
regularly
show
up
and
work
on
the
project
all
the
time,
if
that's
helpful,
for
kind
of
engaging
what
audience
you
wanna.