►
From YouTube: Working Group: 2020-09-24
Description
Experimental Mode: https://github.com/buildpacks/rfcs/pull/115
A
A
B
A
A
D
C
B
B
B
I
think
it's
now
49
is
what
the
number
ended
up
being
and
she
pulled
out
experimental
because
it
wasn't
needed
immediately,
and
this
was
kind
of
the
result
of
some
of
the
conversations
we
had.
But
then
me
thinking
about
it
more
and
so
there's
that
other
kind
of
experimental
kind
of
rfc
as
well,
that
joe
started
that
is
kind
of
built
more
around.
B
B
So
I
set
I
want
to
have
inside
a
lifecycle,
tom
hall
way
to
kind
of
specify
experimental
modes
for
both
build
pack
and
platform
since
they're
two
different
specifications
that
have
two
different
versioning
schemes,
and
one
of
the
things
that
I
settled
on
was
basically
this
alphanumeric
kind
of
thing
where
it
makes
it
really
clear
that
this
is
not.
This
is
experimental
and
not
like
the
normal
kind
of
versions
that
we're
supporting
it.
Just
kind
of
helps
make
that
clear,
there's
a
bunch
of
open
questions.
B
B
How
do
we
want
to
deprecate
and
kind
of
remove
them,
because
we,
I
think
emily
brought
up
race
and
concerns
that
make
a
lot
of
sense
around
like
we.
Don't
just
want
to
have
these
things
hang
around
forever,
but
we
also
don't
want
to
just
like
rip
them
out
from
under
people
if
they're,
depending
on
it.
B
Like
the
modes
and
morning
and
errors
that
a
platform
could
set
or
build
pack,
it's
that
or
platform
could
set
for
kind
of
how
it
wants
to
treat
like
maybe
a
platform
never
wants
to
support
experimental.
So
if
you
use
experimental
features,
you
can
like
fail
that
for
like
a
buildpack
api,
so
yeah,
I
think
more
or
less.
That
is
like
the
bulk
of
the
main
proposal,
and
then
I
listed
some
kind
of
alternatives
of
like
we
could
drop
alphanumeric
thing.
B
I
think
that
does
limit,
potentially
the
scope
of
the
kind
of
features
we
could
put
into
experimental
because
it
would
they'd
have
to
be
kind
of
you'd
have
to
minimize
the
impact
across
the
entire
spec
to
make
sure
you
can't
extract
it,
but
that
you
know
that's
an
alternative.
Potentially
we
can
do
both.
So
I
don't
think
it's
a
one
either
or
yeah.
That's
probably
the
quick
overview
of
the
rc
and
I'll
open
it
up
for
discussion
and
comments.
D
I
have
a
question
so
sort
of
in
the
original
rfc,
where
I
proposed
experimental.
What
distinguished
it
from
supported
or
deprecated
was
that
it
wasn't
the
definition
of
that
api
like
what
was
supported,
could
change
between
releases
sort
of
without
warning.
So
it's
the
kind
of
thing
that
you
wouldn't
necessarily
depend
on
or
that
we
weren't
giving
people
a
guarantee
that
we
wouldn't
break
later.
D
B
I
guess
I
was
thinking
originally
of
just
making
immutable
because
it,
I
think,
just
makes
it
easier
for
users
to
follow
of
of
just
like
you
can
check
potential
like.
Maybe
we
there's
a
thing
where
you
can
see
what
is
in
alpha
one
and
then
what
is
in
alpha
two
I'm
also
open
to
like.
If
we
release
a
new
version
of
the
life
cycle,
that
would
change
it,
the
equivalent
would
be.
B
A
I
have
a
very,
I
think,
it's
very
much
along
those
lines,
but
I
guess
have
more
or
like
a
stepping
back
a
little
bit
semantic
question
about
it
when
we
say
experimental
api
in
that
list
to
me
that
communicates
like
the
life
cycle
has
experimental
support
for
this
api
version
right
and
when
you
take
an
api
version,
and
you
put
dash
alpha
at
the
end
to
me
that
says
this
api
version
is
an
experimental
api
itself
right,
but
those
mean
like
totally
different
things.
One
means
the
in
the
implementation
of
this
component.
A
I
have
I've
experimentally
attempted
to
implement
this
particular
version
of
the
api
that
it's
a
real
version
of
the
api.
That's
defined
as
it
is,
and
my
implementation
of
it
is
somehow
experimental.
You
know
it's
maybe
not
ready
to
go
yet
it
hasn't
met
all
the
requirements
yet
right
and
then,
if
you
have
a
you
know
like
dash
alpha
something
in
the
version
number
itself
to
me
that
communicates
this
this
this
definition
this
the
way
this
is
specified
is
experimental.
We
may
change
how
it's
specified
in
the
future.
A
If
that
makes
sense,
it
seems
like
we're.
We're
talking
about
the
the
specification?
It's
it's
not
clear
to
me.
If
we're,
if
we're
talking
about
the
implementation
or
the
specifications
experimental,
I
think
we're
talking
about
the
specification
and
if
that's
the
case,
I
wonder
why,
like
does
it
make
sense
to
call
it
out
as
an
experimental
field
within
the
component
itself,
where
you'd
imagine
that
would
be
talking
about
the
component.
A
Yeah,
it's
like
if
100
alpha
one
is
is,
is
an
experimental
version
of
100
right
or
with
1
0
right.
If
1
0,
alpha
1
is
an
experimental
version
of
1
0,
then
it
seems
like
that's
something
that
the
life
cycle
can
either
support
or
not
support
right
and
whether
it's
the
component
doesn't
decide
whether
it's
experimentally,
supported
because
this
descriptor
comes
with
a
component
like
I'm
not
sure.
I
understand
what
the
meaning
of
having
a
separate
field
is.
A
Does
that
sort
of
make
sense
it
seems
like
if
we
want
different,
you
want
to
pass
a
flag
through
that
says
this
is
you
can
only
run
experimental
versions
here
and
we're
modifying
the
version
numbers
to
reflect
that
the
versions
themselves
are
experimental.
Then
that's
that's
how
we
should
key
on
making
that
determination.
B
B
For
like
the
supported
key,
like
I
feel
like
supported,
like
at
least
the
name
of
supported
versus,
like
I
think
if
the
word
was
available
versus
supported,
I
would
feel
differently
about
that,
but
I
feel
like
supported,
implies
like
some
level
of
support,
maybe
by
just
the
name.
I
don't
know
if
that
makes
sense.
Steven.
A
I
think
I
get
what
you're
saying,
but
it's
like
if,
if
the
life
cycle
guarantees
that
it
or
the
the
word
supported
there
to
me,
when
you
put
an
alpha
version
next
to
it,
implies
that
the
life
cycle
is
saying.
Yes,
we
we
totally
implemented
this
alpha
version
of
the
api
like
we
think
it
is
exactly
right.
A
We
will
support
the
api
itself,
maybe
crap
right
like
it,
may
not
work
right
to
solve
your
problems,
but
it
it
matches
what
the
specification
says,
and
so,
if
we're
going
to
introduce
an
experimental
field
there
like-
and
maybe
maybe
the
problem
is,
that
supported
is
too
strong
a
word
and
we
could.
We
could
think
about
that,
but
the
if
we're
going
to
introduce
experimental
there.
In
this
context,
I
really
read
it
as
like
the
implementation
we've
done
in
the
life
cycle
itself.
It
could
be
a
way
to
say
like
here.
A
We
have
experimental
support
for
1-0,
which
would
mean,
like
we
tried
to
implement
the
1-0
spec,
but
there
might
will
still
be
broken
stuff,
so
only
use
the
life
cycle
for
1-0
at
your
own
risk
right.
I
I
don't
know
if,
like
kind
of
stepping
back
further,
I
don't
know
which
of
those
two
things
we
actually
want.
Well,
we
we
might
not
actually
want
experimental
specification
versions.
A
We
may
want
to
say
that,
like
we
think
we
specified
1
0
really
well
and
that's
the
normal
case
and
we've
added
support
to
the
life
cycle
for
it,
but
we're
not
sure
if
it
really
works
super
well,
yet
so
we're
going
to
put
that
experimental
field
and
that
that
might
be
what
we
need.
You
know,
but
that
means
not
versioning
the
apis
differently
right
or
we
might
be
saying
we're
not
sure
about
some
spec
changes.
We've
made
and
we've
released
an
alpha
version
of
the
spec
or
whatever,
and
does
that
sort
of
make
sense.
D
Yeah
that
distinction
makes
a
lot
of
sense
to
me.
I
think
an
example
of
the
latter
case,
where
we're
not
sure
about
the
spec,
is
the
current
stack
back
conversation
right.
I
think
we
want
to
have
a
thing.
People
can
try
before
we're
sure
exactly
what
the
spec
for
that
looks
like
does
that
fit
with
everyone's
understanding.
A
B
That
was
my
original
thought.
Obviously,
it's
just
a
thought
and
people
need
buy-in,
but
yeah
I
mean
I
I
think
I
was
going
along
with.
Basically
what
emily
was
thinking
as
well
with
some
of
the
stack
pack
stuff
is
like.
I
think
we
feel
feel
good
about
the
sac
pack
stuff,
but
it
feels
like
we
need
to
try
out
some
of
the
even
not
even
just
there's
for
sure.
B
If
that
makes
sense,
it
makes
sense.
But
I
agree
they
are
separate
things,
but
I
I'm
curious
like
how
often
you
need
to
tackle
both
of
those
things
too,
and
I
I'm
happy
if
like
it,
if
what
we
need
to
do
is
just
remove
experimental
from
and
put
this
into
supported
like
I
am
not,
that
is
not
a
hill,
I'm
gonna
die
on
or
anything.
E
So
what
is
the
value
of
the
field?
It
seems
like
that's
what
we're
talking
about
right
and
how
would
it
actually
be
used
outside
of
just
human
comprehension
like
I
know,
for
deprecated
we
could
throw
out.
You
know
deprecation
warnings
when
you're
using
a
certain
api.
Do
we
anticipate
doing
the
same
thing
for
experimental?
E
A
The
major
use
cases
automatically
informing
the
user
or
forcing
the
user
to
take
some
action
before
they're
allowed
to
use
the
dangerous
thing.
I
see
that
to
me
that
that
separation
of
implementation
and
and
specification
is
important
in
that
context,
specifically
because
it
communicates
like
the
you
know.
If
the
user
is
using
some
functionality
that
might
be
broken
right.
That
feels
like
a
different
kind
of
warning
to
the
user.
B
A
good
example
right,
like
whatever
the
next
api,
actually
makes
it
out
and
say
like
point
seven
or
whatever
right,
and
we
feel
good
about
it,
but
the
api
and
it
makes
it
and
then
we
just
move
it
and
take
surround.
So
I
think
that
case
is
clear.
What
does
it
mean
to
have
like
the
experimental
it's
like
well
implemented,
but
the
spec
is
not.
B
A
I
I
think
it's
still
like,
maybe
some
like
real
world
examples
of
this
or
like
tamil
right
now
like
tamil,
is
it
you
know
100
rc2,
but
the
implementations
of
different
implementations
of
oh
rc2
are
actually
really
good.
They
meet
that
spec,
exactly
they're,
just
not
show
up
stream
if
they
want
to.
You
know
change
it
in
the
definitions.
A
For
for
what
100
is
like,
I
could
see
a
world
where
we
get
stack
packs
or
we
get
stack,
packs
down,
really
implemented,
really
well
right,
conoco's
behaving
very
nicely,
we're
doing
all
the
snapshotting
and
everything
it's
it's.
It's
not
nothing.
We'd
worry
about
somebody
using
in
its
current
state
right,
but
we
want
more
feedback
before
we
say
like
because
of
the
performance
implications,
and
things
like
that.
We
want
some
more
real
world
feedback
before
we
want
to
like
turn
it
on,
for
all
users
automatically,
with
no
warnings
for
everybody
to
use
right.
A
D
D
If
we're
going
to
say
we're
going
to
take
this
api
and
we
support
it
and
that
we're
going
to
deprecate
it
and
we
need
to
support
alongside
other
versions,
I
do
want
us
to
get
it
out
there
with
some
level
of
confidence
that
we
aren't
going
to
kill
ourselves
trying
to
support
support
this
because
it
was
hastily.
You
know
we
didn't
think
through
all
the
details,
but
that
isn't
necessarily
what
we've
been
talking
about
recently
wanting
to
do
with
stack
packs,
which
is
just
like
get
something
out
there.
So
people
can
try
it.
A
D
Imagine
how
we
would
do
stack
packs
with
this,
and
let's
say
we
took
the
experimental
field
out
and
we
were
having
experimental
apis.
So
we
say:
oh,
we
think
eventually,
stackpacks
are
going
to
ship
in
buildpack
api07,
but
we
want.
We
aren't
exactly
sure
what
we
want
the
api
to
look
like
so
we'll
at
a
certain
point,
we'll
call
something
07
alpha
1
and
the
life
cycle
will
implement
that
and
then
people
can
try
it
out.
A
B
Enough
that
we
want
to
call
it,
oh,
you
can
cut
it
out
of
oh
yeah.
It's
an
alpha
release
right,
like
maybe
stack,
packs,
need
like
worst
case
scenario
right,
like
stack
packs,
we
got
useful
feedback
and
it
was
not
what
we
wanted.
It
needs
to
go,
maybe
back
to
the
drawing
board
or
something
right
like,
and
then
we
just
bump
out
of
0.7
right.
D
I
do
think
it
gets
a
little
weird
if
you
want
to
make
other
changes
in
o7.
We
would
have
merged
all
this
stuff
in
this
branch,
then
we'll
rip
it
out
and
then
the
live
cycle,
because
we
don't
want
to
hard
drop
an
api
on
the
ground
between
releases
without
at
least
telling
people
it's
going
to
be
removed,
we'd
be
supporting
oh
seven,
alpha
version
of
stack
packs
and
oh
seven,
that
has
no
snack
packs
and
like
an
o8
alpha
that
has
a
slightly
different
version
of
stack
packs.
C
Well,
yeah,
that's
actually
a
good
question.
Right
like
I
was
asking,
are
experimentals
linear
or
are
they?
Is
it
a
forking
thing
like?
Could
we
have
an
experimental
stack
packs
and
an
experimental
inline,
build
packs
and
experimental
offline
packages
that
all
kind
of
go
like
maybe
off
the
offline
packages?
Experimental
doesn't
like
you
can't
use
stack
packs
with
offline,
build
packs.
D
If
we
start
treating
these
sort
of
as
unstable
features,
rather
than
alpha
versions
of
the
next
api,
we
run
into
like
combinatorial
explosion,
problems
where
like
okay,
so
I
want
to
use
the
experimental
stack
packs,
but
with
which
api
and
do
they
all
have
the
right
information
there.
It
starts
making
lifecycle,
hideously,
complicated.
C
No
yeah,
I'm
definitely
not
advocating
for
the
forking.
I
actually
like
the
linear
better
in
part,
because
I
think
it
makes
it
easier
to
deal
with
in
the
code
like
we
can
just
put
everything
in
main
and
be
pretty
confident
that
it's
either
gonna
stay
experimental,
but
it.
But
like
that
way,
we
get
to
have
everything
play
with
each
other
well
in
advance
of
a
release.
C
C
B
C
Like
maybe
alpha
is
like
a
collection
of
those
diffs,
I
don't
know,
does
it
I
yeah.
I
don't
know
where
I'm
going
with
that,
like
the
things
that
are
important
to
me.
Are
that,
like
we
are
able
to
put
the
different
experiments
in
the
same
branch
in
the
code
and
that
yeah
and
then
maybe
that
this
that
I
can
see
the
diff
in
the
spec,
although
I'm
not
married
to.
C
C
Yeah,
I
mean
I'm
sure
you
have
to
like
rebase
and
things
like
that,
but
but
I
I
just
I
can't
figure
out
like
I'm
trying
to
think
through
it
now,
but
like
I
can't
figure
out
how
that
corresponds
to
how
we
do
like
naming
of
the
branch
or
tagging
and
in
the
spec
I
don't
know
any
feature
branches
sort
of
it's
like.
I
think
it's
like.
I
want
to
push
that
that
complexity
into
the
spec
rather
than
having
it
in
the
implementation.
C
E
C
Oh
yeah,
I
mean
it's
just
words
right
like
we
see
that
in
I
think
in
project
tamil
a
little
bit
where
it's
like
you
have
to
reference,
something
that
is
in
the
mainline
spec
or
like
duplicate
it
like
yeah.
I
agree,
there's
like
this
weird.
There
could
be
these
like.
Not
everything
is
completely
separate
and
it
has
to
account
for
those
parts
where
it
overlaps
like
it's
like
anything,
that's
an
extension
or
would
be
a
separate
experimental
directory
is
not
the
kind
of
thing
that
you
could
just
hit.
The
merge
button
on.
E
C
Yeah
and
I'm
saying
copy
paste
those
sections
and
rewrite
them
in
the
extension.
Oh,
I
see
you
know
what
I
mean
like
yeah,
but,
like
that's
what
I
mean
by
it's
just
words
like
yes.
That
means
you
can't
just
like
simply
merge
them
like
actually
moving
it
from
experimental
into
the
course
back
would
require
reworking
them
in
the
sense
of
like
reworking
the
pros.
E
B
Because,
like
you're
basically
saying
I
want
to
be
able
to
flag
in
because,
if
you're
rewriting
parts
of
the
main
spec
in
experimental,
like
no
matter
how
small
it
is,
it
means
that,
like
there
has
to
be
a
way
for
me
to
run
this
without
having
that
kind
of
behavior
turned
on
right
like
because,
if
I
go
and
read
say
the
0.7,
whatever
alpha,
spec
and
there's
an
extension.
That
is
stack
packs.
But
it
impacts
like
the
behavior
of
how
it
works.
And
I
read
that-
and
I
think
it
works
this
way.
B
D
B
C
D
Maybe
there
are
some
things
for
which
it's
worth
it,
even
though
that
is
a
high
bar
to
clear,
I
feel
like
either
way
we're
not
off
the
hook
right.
I
think
we
can
make
it
such
that
you
either
have
to
specify
everything
up
front,
and
then
you
can
merge
it
into
the
normal
spec
or,
if
you
want
it
to
behave
like
an
experimental
feature
that
happens
through
extension,
specs.
D
C
And
not
always
desirable
too
right
like
yeah.
I
think
I
think
personally,
I'm
thinking
about
it
too
much
in
the
context
of
stack
packs
where
that
is
achievable.
Right
like
if
you
turn
off
stack
packs,
everything
should
work
the
way
it
normally
does,
but
that
is
definitely
not
true
for
other
things
and
that,
like
in
in
in
a
way
that
we
might
not
want
like
we
might
want
the
experimental
thing
to
be
something
that
is
antithetical
to
the
way
it
is
today
right.
D
D
D
A
Know
I
think
this
rfc
to
the
place
we've
we
would
take
it.
I
think,
which
is
you
know
the
ability
to
put
alpha
versions
in
the
in
the
list
of
supported.
You
know
things
is
more
like
an
rfc
about
pre-release
functionality.
Right
to
say
the
life
cycle
can
work
on
a
pre-release
version
of
the
spec,
and
that
would
mean
that
we
should
cut
pre-release
versions
of
the
spec.
Have
linear,
pre-releases
use
it
use
it
in
order
to
demo.
A
You
know
a
version
of
the
specification.
That's
flowing
linearly
generally
right
that,
where
we're
just
not
sure
if
we're
ready
to
cut
the
next
release
yet
right,
if
we
find
that
functionality
useful
for
the
types
of
things
we're
about
to
launch,
then
I
think
is
a
good
rfc.
If
that
makes
sense,
if
we
don't
find
that
functionality
useful
in
the
short
term,
then
we
could,
we
could
wait
on
it
until
we
need
that
kind
of
sort
of
linear
pre-release
functionality.
A
If
we
want
to
run
stackpacks
through
the
kind
of
linear
prerelease
functionality,
then
I'd
say
that
could
be
a
kind
of
reason
to
keep
going.
If
we
want
to
do
something
different
with
stackpacks,
where
it's
more
like
you
know,
this
is
this-
is
something
that's
optional
to
for
platforms
to
implement,
as
we
continue
to
release
the
spec,
you
know
separately
and
and
run
new
versions
of
it
that
you'd
tack
on
top
that's
still
experimental
as
an
extension
right,
then
I
I
don't
think
you
know
like
at
least
in
the
way
this
is
described
right
now.
A
B
A
A
What
we
want
for
100
is
really
about
experimentals
api,
it's
like
a
pre-release
api
version,
not
not
pre-release
functionality
and
pack
right,
and
so
so
I'd
say
like
if
you
move
the
experimental
stuff
to
that
supported
flag.
We
could
get
this
through
for
helping
with
10,
but
it
may
not
cover
the
stack
pack.
Use
cases
would
be
my
gut.
B
Yeah,
I
guess
there's
questions
for
me
around
like
like
I.
I
definitely
hear
like
emily's
concern
of
like
some
of
the
complexity
of
like
supporting
a
bunch
of
api
modes
too,
and
I
wanna.
Maybe
this
is
like
on
a
case-by-case
basis
and
that's
out
of
scope
of
this
rc,
but
like
what
are
people's
gut
feeling
of
supporting
like
say
we
do
a
1
0
alpha
one
right
like,
and
then
we
do
a
10
alpha
2
like
what
is
the
expectation
that
we
want
to
give
our
users
of
like?
B
B
D
C
C
C
A
I
wanna,
I
think
this
is
gonna,
get
very
complicated
if
we're
thinking
about
experimental
versions
of
those,
including
an
extension
that
then
move
forward
to
subsequent
versions.
I
have
a
simpler,
maybe
controversial
suggestion,
but
I
think
would
might
help.
So
in
the
end,
if
we
choose
to
make
separate
extensions
right
that
inversion,
those
extensions
right
like
out
of
band
of
the
normal
release
process,
we
end
up
creating
a
separate
extensions
version.
A
D
A
You
know
version
numbers
between
those
components
when
really
it's
one
version
number
that
you
know
describes
which
two
components:
either
the
life
cycle
and
the
platform
or
the
life
cycle
in
the
build
pack
each
of
those
contracts.
You
have
a
thing
on
each
side
right
and
I
think
one
version
number
is
probably
enough
to
describe
the
support
contract
between
those
two
things
and
so
as
an
alternative
to
creating
multiple
version
numbers
we
could
and
as
an
alternative
to
submitting
stack
packs
as
an
extension
into
the
spec
right.
A
D
A
Why
we
have
may
in
the
spec
right
yeah,
then
this
could
be
a
proper
part
of
the
spec
that
is,
is
documented.
We
can
bump
all
the
version
numbers
we
can
treat
it
like
normal.
We
don't
have
to
deal
with
any
of
these
problems.
If
that
makes
sense,
we
sacrifice
a
little
bit
of
using
version
numbers
to
communicate
things
very
clearly,
because
the
version
number
won't
have
alpha
or
whatever
in
it,
but
it
seems
like
that.
A
We're
never
going
to
be
able
to
communicate
clearly
what
we
want
here,
because
it
really
does
run
out
of
band
of
the
thing
and
we
can
use
the
ability
for
the
spec
to
define
itself
as
whatever
it
wants
to
be
right
in
order
to
add
an
additional
feature
that
just
gets
integrated
normally
and
then
we
don't
don't
have
to
deal
with
the
problem.
I
think.
A
I
think
introducing
that
extension
to
the
version
creates
the
complexity
where
it's
difficult
to
understand
what
we're
releasing,
if
that
makes
sense
and
what
the
next
version
would
be,
but
but
it
doesn't
mean
that
you
couldn't
communicate
this
very
clearly
in
other
ways
right,
so
you
could
release
the
next
spec
version
inside
of
the
specs
say
the
following
have
a
separate
pages.
The
following
features
are
experimental
features
within
this
proper
api
version
to
enable
them
you
must
pass.
You
know,
platform.
A
You
know
you
couldn't
denote
that
in
the
version
number
of
the
contract
itself,
but
like
again,
I
think,
as
soon
as
you
start
messing
with
that
too
much,
we
end
up
with
a
lot
of
complexity
and
how
we
want
to
integrate
that
change
into
future
versions
and
when
we're
going
to
drop
it,
the
user
could
still
very
clearly
have
to
indicate
that
they're
opting
into
that
feature
by
something
that
we've
defined
in
the
spec.
That's
very
clear
to
the
user.
B
Yeah
I
mean
this
sounds
a
lot
like
unstable
feature
stuff,
but
it's
just
I
mean
it's
in
the
spec,
the
mainline
spec.
I
guess
the
the
downside
to
some
degrees
like
if
you
say,
have
0.7
and
you
have
like
iteration,
one
of
stack,
packs
at
experimental,
and
then
you
have
point
eight.
That
also
has
an
experimental
version
of
stack
packs
and
they
function
wildly
differently,
because
we've
learned
stuff
from
the
0.7
thing
does
lifecycle
need
to
support
both.
A
B
A
B
Right
but
I'm
saying
like
if
I
go
back
to
if
I'm
like,
I
don't
want
to
move
to
point
eight
of
the
spec
right
for
bill
pack
or
platform
api
right
and
we're
saying
this
is
experimental.
So
it
can
change
right
and
does
the
life
cycle
need
to
maintain
the
two
different
implementations
of
the
stackpack
feature
or.
B
A
An
alternative
is,
we
could
not
spec
this
and
be
a
feature
of
the
life
cycle
end
of
pac.
That
is
an
experimental
feature
of
the
implementation.
That
is
not
in
the
specification
right,
but
then,
then,
you
kind
of
lose.
The
ability
to
use
the
specification
versions
to
you
know
meaningfully
indicate
that
the
buildback
can
or
can't
support
the
functionality,
and
that
doesn't
seem.
B
A
A
But
but
I
see
what
you're
saying
about
like
well,
that
means
that,
like
when
you
bump
to
the
next
version,
things
could
change
completely
right
and
so,
like
support,
build
pack,
says
0.7
versus
bill.
Peck
says
0.8
right
means
like
the
behavior
could
be
very
different.
Suddenly
right
and
you'd
have
to
ensure
that
you're
looking
up
the
right
thing,
the
life
cycle
would
have
to
support
both
to
continue
to
support
point
seven
right.
A
A
I
mean
because
it's
experimental,
though
things
can
break
in
different
situations
right,
so
we
could
say
like
because
it
because
you
don't
have
to
implement
that
feature
in
point.
Seven
life
cycle
could
keep
point
seven
around
right,
but
not
keep
the
stack
pack.
The
old
stack
back
implementation
of
0.7
around
because
it's
optional
in
0.7
right.
You
could
actually
lose
that
when
we
bump
lifecycle
the
next
version
and
then
build
packs
on
0.7
with
stack
packs
that
are
expected
to
work
would
stop
working
and
we
could
say
well,
you
know
it's
really.
D
E
A
To
version
the
life
cycle,
along
with
the
thing,
if
we
needed
to
so
it's,
it
is
flexible
and
is
just
as
flexible
as
other
ways
of
doing
it
right.
It's
either
it
works
or
it
doesn't
work
when
we
like,
no
matter
how
we
slice
the
versions,
it's
going
to
be
the
same
question
but-
and
this
is
really
simple,
so
it's
wide
recommended
sorry.
I.
B
Guess
we
only
have
three
minutes
left.
I
I
guess
for
me
like
some
of
the
questions
is
like
what
I
do
if
that's
rc,
but
also
like,
I
think
what
you're
the
kind
of
trade-off
here
is
like
you,
either
want
to
move
the
spec
versions
forward,
or
you
want
to
kind
of
stabilize
a
feature
before
releasing
it
into
a
spec
right,
which
I
guess
is
what
the
experimental
api
is
that's
suggested
by
rc
or
like
we're.
B
B
Yeah,
that's
the
not
the
trap,
but
the
difference
like
like
one
is
about
stabilizing
it.
So
when
point
seven
comes
out
that
the
api
is
hopefully
finalized
or
we
feel
good
about
it,
whereas
the
other
one
is
like
we're.
Just
gonna
carry
this
kind
of
thing
through
through
multiple
versions,
potentially
right.
C
D
Welcome
to
design
your
prod
system
on
it,
but
it
means
when
you
pull
in
a
new
lifecycle
release.
You
have
to
be
careful
about
it
and
then
it's
on
you,
but
you
sort
of
opted
in,
whereas
if
you're
in
api
land
we've
like
put
guard
rails.
So
you
can't
treat
yourself
in
the
foot,
and
this
is
saying
I
take
responsibility
for
shooting
myself
in
the
foot.
But
I
want
to
be
an
experimental
and.
C
D
D
Gets
confusing
to
me
to
understand
and
hard
to
implement,
I
feel
like
I'm
more
comfortable
with
it
when
it's
api
is
experimental,
which
means
whatever,
and
that
gives
us
the
opportunity
to
try
these
things
out
and
people
who
want
to
cautiously
pull
in
new
lifecycle
versions
rather
than
optimistically
pull
in
new
lifecycle
versions.
The
chance
to
try
things
out
and
the
fact
that
they
use
that
string
gives
people
an
appropriate
warning
that
maybe
they
shouldn't
try
it
out
and
prod
for
their
million
customers.