►
From YouTube: 2021-02-18 Slippers Release and Versioning Strategy
Description
Javier Garcia, Stephen McGuinness, and Tyler Williams talk about Slippers versioning and release strategy including:
What we will be releasing (component library, design assets)
How we will be versioning it (semantic versioning)
How often we will be releasing Slippers, at what cadence, and how we will think about this process overall.
Slippers UI: https://gitlab.com/gitlab-com/marketing/inbound-marketing/slippers-ui
Agenda: https://docs.google.com/document/d/1tEhzFJYMOzJImLFObPcVUa85e3YHbRYg6m05MyEoXIQ/edit?usp=sharing
A
So
I'll
kick
us
off
here
in
the
agenda.
There's
a
couple
links
to
the
documentation.
The
mr
that
I
was
talking
about
javi
had
shared
with
us.
This
releasing
design
systems
post,
which
is
honestly
like
I
for
the
most
part.
I
think
this
first
iteration
I
just
like
copied
the
things
that
were
relevant,
because
I
thought
that,
like
it
made
a
lot
of
sense,
I
thought
it
was
great
thanks
for
finding
the
resource
by
the
way
avian
thanks
for
sharing
it.
A
I
thought
it
was
awesome
and
it
felt
like
super
applicable
to
our
goals
and
what
we
want
to
get
out
of
it.
So
I
basically
just
grabbed
the
things
that
apply
to
us
and
that
I
left
in
the
mr
open
questions
and
for
me
I
feel
very
comfortable
about
the
what
code
is
getting
released
in
versioned
and
how
and
I
just
do
not
have
the
context
for
design
assets
and
what
that's
like.
A
So
I
know
you
two
have
the
experience
there
to
help
fill
in
those
gaps
for
me
or
at
least
point
us
in
the
right
direction
to
get
started
with
these
conversations.
So
I
think
we
can
take
care
of
the
easy
part
first,
which
is
releasing
and
versioning
the
code
that
is
slippers
right
and
so
just
looking
at.
A
The
first
is,
and
they
kind
of
come
as
a
set,
but
the
nice
thing
is
that
we
do
have
them
decoupled,
so
they
can
be
used.
They
can
be
applied
differently.
The
first
is
the
compiled
css.
What
our
post
css
pulls
out
of
tailwind
and
pulls
out
of
our
custom
css.
Thank
you
javi
for
the
link
appreciate
it.
This
is
the
code
base
itself
right
and
when
we
release
inversion
things
they
turn
into
these
assets
here
that
can
be
consumed
by
different
package
managers.
Right
so
compile.
A
Css
is
one
of
them
and
then
our
vue.js
library
bundle,
and
so
that
is
our
compiled
css
and
all
of
these
files
are
different.
Iterations
on
that
compiled
vue.js
component
bundle.
We
don't
need
to
talk
too
much
about
the
the
differences
there,
but
just
know
that
they're
basically
set
up
to
be
imported
in
different
contexts.
If
we
need
to
it
gives
us
a
lot
of
flexibility
with
how
the
package
gets
used.
A
So
that's
what
we're
releasing
and
what
we
are
versioning.
The
way
that
we
are
versioning
is
pretty
standard
across
software
development,
semantic
versioning,
which
in
itself
is
well
versioned
and
well
maintained
and
gitlab
uses
it,
and
it's
it's.
You
know
for
folks,
who've
been
working
with
specific
versioning.
I
think
it's
easy
to
conceptualize
it's
a
little
bit
different
than
like
what,
if
you're,
not
familiar
with
it,
it's
useful
to
think
about.
A
Like
there's
three
numbers
right.
There
is
an
x,
a
y
and
a
z.
I
have
an
example
here:
zero
point
y
point,
z,
you'll,
see
this
in
a
lot
of
software
versioning
and
basically,
you
can
think
of
it
as
the
words
major
minor
and
patch,
and
so
the
idea
is
that
the
major
version
includes
things
that
are
incompatible
with
other
major
versions,
so
things
that,
if
you
were
to
like,
if
you
had
you
know
one
of
slippers,
one
dot
whatever
and
you
move
to
v
two
they
would
be
incompatible.
A
Something
would
break
if
you
tried
to
use
the
same
code
between
the
two
of
them.
The
minor
version
is
not
breaking
so
1.1
1.2,
they
should
work
together
and
the
minor
version
is
usual,
usually
just
there
to
denote
that
something
has
been
added,
a
new
feature,
a
new
functionality,
something
extra
right
and
then
the
patch
again
is
not
breaking
changes,
and
it's
just
for
bug
fixes.
A
So
it's
to
fix
things
that
broke,
not
in
the
sense
of
like
incompatibilities
between
major
versions
but
actual
bugs,
and
so
that
gives
us
a
fine
grain
way
to
really
denote
like
when
we
release
this
software
when
it
goes
out
into
the
world
to
be
consumed
elsewhere.
How
are
we
telling
people
like
what
state
it
is
in
and
how
do
we
refer
back
to
that
in
and
of
ourselves?
A
Semantic
versioning
requires
a
little
bit
of
normalization.
It
requires
some
process
and
overhead
and
in
early
development
phases,
which
is
where
we're
at
with
slippers
the
recommendation
for
a
version.
Zero
is
that
you
stay
on
version
zero.
You
don't
increment
zero
one,
two
three
in
the
major
column
and
you
basically
say
version
zero
is
unstable.
Things
will
break
between
our
minor
versions
and
then
you
just
increment
your
minor
version.
A
As
you
make
changes
for
us,
there's
a
cadence
that
I
think
will
work
really
well
we're
already
working
in
two-week
sprints,
and
so
I
think
you
know
basically
incrementing
our
minor
version
to
be
in
sync
with
our
sprints
is
the
way
to
move
forward
and
we
can
use
our
patches.
So
at
the
end
of
each
sprint
we
release
the
package
to
the
package
registry
and
we
say
here's
the
new
version
0.4.5
so
on
and
so
forth
in
the
middle
of
a
sprint
in
the
middle
of
those
two
weeks.
A
A
So
people
looking
at
this
when
they
see
v0
they'll,
say
oh,
like
I
shouldn't
depend
on
this
always
working
between
minor
upgrades
right,
and
so
it's
a
really
good
way
to
communicate
to
external
folks
or
potential
collaborators
about
the
state
of
the
version
and
then
finally
managing
it
automatically
like.
I
said
we've
got
a
cadence
of
doing
this
at
the
end
of
each
sprint
iteration,
and
to
that
end
we
can
automate
it
with
git
lab
ci
cd.
A
So
that's
what
I
had
for
this
that's
kind
of
that
is
the
extent
of
the
things
that
I
feel
very
confident
on
and
that
I
have
like
stronger,
like
reasoned
opinions
about
and
I'd
love
to
like.
If
either
of
you,
two
have
questions
about
those
items
or
we
can
also
just
move
on
javi
you've
got
points
here
that
we
can.
We
can
get
to.
B
Yeah
thanks
I'm
just
going
to
go
through
the
points
because
it
doesn't
seem
like
we
have
super
crazy
questions,
something
that
I
kind
of
wanted
to
bring
up
was
just
like
the
concept
of
sustaining
past
versions
within
git
itself.
We
can
do
that
through
the
npm
package,
obviously,
because
there's
like
different
versioning
within
that
itself,
I
was
wondering
if
it
made
sense
for
us
to
do
so,
because
I
know
that
pajamas
in
particular
has
something
like
that
when.
A
B
That's
kind
of
like
where
my
head
is
at
for
that.
There's
also
like
under
the
related
note
of
packages
coming
going
out
of
date.
You
know,
as
software
moves
things,
will
change
and
so
having
something
set
up
where
non-breaking
changes
can
be
automatically
updated,
would
be
really
nice,
especially
as
we
have
all
of
these
packages
they're
flying
in
and
out,
yeah.
A
Yeah,
we
certainly
by
default.
Those
old
versions
will
stay
in
the
registry,
and
you
mentioned
here
the
tags
and
releases
gitlab
features
which
we
can
dog
food
and
use
as
well
for
this.
So
the
answer
is
like
absolutely.
We
should.
I
think
that,
there's
you
know
it's
good
to
know
it's
good.
To
do
it's
good
to
start,
I
think
in
version
major
version
zero
as
we're
going
through
rapid
development,
it's
less
critical
in
a
lot
of
ways.
C
Yeah,
just
on
that,
I
think
it's
it's
good
for
us
to
be.
You
know
supportive
of
previous
versions
as
we
as
the
system
gets
built,
bigger
and
more
diverse
and
more
robust,
and
but
one
thing
that
might
serve
us
in
the
realms
of
success
is
to
you
know,
incentivize
teams
to
make
sure
that
they're,
you
know
never
more
than
I
know
two
or
three
versions
away
from
the
most
recent,
because
the
further
they
get
away
the
more
expensive
that
or
more
critical
that
can
become
we've
run
into
breaking
changes.
C
C
You
know
an
ideal
cadence
that
we
want
to
adopt
of
like
hey
we're
you're
now,
two
fair,
two
versions
or
three
versions
behind
or
whatever
it
is,
and
it
might
be
an
idea
to
begin
to
think
about
adopting
the
code
to
make
sure
that
you're
not
too
far
off,
because
that's
where
things
can
get
probably
problematic.
It
sets
ourselves
up
for
a
degree
of
success
as
well
by
managing
that
expectation,
because
if
we
leave
it
hanging
and
teams
never
really
adopt
anything
because
they
just
become
familiar
with
it
and
it
could.
B
Okay-
and
I
had
one
quick
other
point
about
that-
I
don't
know
within
the
gitlab
ui-
you
can
have
like
a
storage
space.
So
if
you
go
to
the
very
top
there's
like
that,
what
does
that
actually
mean
because
it
just
points
to?
Is
it
talking
about
like
branches
or
like?
I
actually
just
had
that
question
that
I
I
was
just
confused
about.
I
was
looking
at
it
one
day.
A
A
Looking
at
the
like
differential
between
these
two,
where
we've
got
two
megabytes
of
files
and
then
you
know
270
megabytes
of
storage,
I
would
guess
that
your
guess
is
right
that,
like
the
storage
listing
has
to
do
with
all
of
the
metadata
that,
like
this
project,
like
this
project
sitting
in
the
rails
instance
of
gitlab
like
how
much
space
is
it
taking
up
on
disk
and
then
the
two
megabytes
of
files
is,
you
know
if
I
were
to
pull
this
down
to
a
computer
that
didn't
already
have
it?
How
much
like?
A
C
B
Okay,
sweet.
I
I
want
to
talk
a
little
bit
also
about
like
figma
releases.
I
think
where
we
ended
up
on
this
is
just
kind
of
like
we
were.
We
were
trying
to
figure
out
like
what
would
make
sense
from
a
design
perspective
like
what's
following
semantic.
Versioning
makes
sense
just
because
we're
doing
it
in
the
code
and
it
makes
sense
to
try
to
follow
it.
B
C
It's
all
good,
and
so
in
terms
of
a
seamless
experience
across
code
and
figment,
I
would
prefer
to
adopt
the
same
naming
convention
that
we
have
for
the
code
repo,
and
we
did
that
at
previous
companies
and
it
was
quite
successful.
It
kept
designers
and
developers
on
the
same
page
that
they're
working
from
the
same
file
or
the
work
from
the
same
version,
at
least-
and
I
do
hear
what
you
say
when
it
comes
to
you
know
it
might
be
overkill.
Something
like
that.
I
agree.
C
However,
I
think
the
overkill
in
this
instance
is
worth
it
because
of
the
the
pain
it
saves
us
in
the
future
by
having
to
refer
back
to
what
is
the
most
referred
to
figure
file
in
existence
or
library,
for
instance,
and
I
think
that
if
we
adopt
that-
and
we
can
have
that
we
can-
we
can
name
release
patches
and
just
just
sequence
them.
Even
if
there's
no
patch
or
bug
fix,
if
they're
kept
in
sequence
it.
It
saves
us
any
kind
of
potential
mitigation
around
confusion.
C
What
might
happen,
what
what's
the
most
what's
the
latest
and
we
try
and
treat
it
all
as
the
same,
because
it
is
it's
all
part
of
the
same
package.
Sigma
is
kind
of
tied
into
the
code.
It's
just
not
as
glamorous.
Perhaps
it's
a
bit
more
basic,
but
as
other
teams
potentially
begin
to
use
this
and
lean
on
it
a
bit
more
and
rely
on
it
a
bit
more,
it's
it's
important
for
us
to
treat
them
in
and
of
the
same,
so
it
doesn't
have
to
be.
C
You
know,
there's
different
ways
in
which
is
as
well
in
which
we
can
manage
them.
We
don't
rely
too
much
on
the
tool
itself,
so
we
set
up
support
channels
in
slack.
We
we
release,
you
know,
or
we
can
automate
that
that
pajamas
does
that
too,
whenever
there's
a
patch
whenever
there's
a
release-
and
there
might
be
some
integration
as
well
with
storybook
so
and
it
can
be
changes
to
the
documentation
around
support,
it
can
be
changes
from
an
example
would
be
accordions.
C
For
instance,
if
we
begin
to
support
different
media
within
those,
so
they're
not
just
static
text,
it
could
be
text
with
cta.
It
could
be
a
video,
it
could
be
a
form
field.
You
know
whatever
route
the
ux
takes
and
certain
blocks
and
components
will
begin
to
have
different
support,
support
for
different
media
as
it
goes.
A
So
is
it
the
case
that
you
can
with
like
a
figma
file
or
a
figma
link,
as
it
is
figma
still
I'm
like
I'm
used
to
xd
for
the
most
part,
but
like
with
a
figma
file?
Can
you
say
like
okay?
This
is
this?
Is
the
slippers
foundation
file
version,
zero
point
y
point,
z
right
and
then
you
can
like
change
that
and
like
you
have
each
version
of
that
is
available
based
on,
like
you
can
like
put
it
in
the
url
or
something
is
that
is
that
findable?
C
I
need
to
double
check
on
that
think
because
right
right
now,
there's
a
master
figma
file
that
we
work
from
and
then
we
build
the
library
and
then
teams
will
pull
the
library
into
their
figma
file.
That's
how
tina
and
jesse
is
currently
and-
and
it's
easy
to
manage
that,
because
it's
internal
they're
they're
on
our
team.
So
it's
easy
to
sort
of
understand
any
pain,
points
or
friction.
If
it
came
to
us,
I
mean
I
mean
I
know
what
we
can.
C
C
A
Sorry,
like
I
think,
you're
answering
the
other
part
of
my
question,
which
is
like
when
we
determine
when
the
figma
for
so
like
in
the
same
way
that,
at
the
end
of
you
know
on
a
thursday
for
sprint
release
for
the
code.
I
say:
okay
like
push
button.
This
is
the
version
it
is
that's
out
in
the
world.
At
that
same
moment,
we
would
basically
say
awesome
whatever
state
figma
is
is
also
that
version
right
is
that
the
correct.
C
Yeah
yeah
and
just
to
bear
in
mind
as
well.
There
are
different
release
notes
that
may
tie
into
figma
that
we
can
release
through
figma
and
that
might
not
necessarily
need
to
include
the
code
documentation
to
mimic
that-
and
this
is
where
we
have
two
sort
of
individual
packages
shall
we
say
and
ultimately
then
we
want
to
have.
You
know:
there's
a
release
package
within
figma,
there's
a
release
package
in
code,
but
then
there's
a
release
package
that
goes
that
references
both.
B
Tyler,
I
dropped
a
link.
Do
you
want
to
after
you're
done
with
that?
Do
you
want
to
open
slippers
foundation
and
then
in
the
search
or
so
click
the
hamburger
and
then
in
the
search,
type
history
and
then
show
version
history,
and
then
I
think
it'll
show
you
like
yeah
like
stuff.
I
think
there's
a
way
to
name
it.
B
C
B
A
Right
because
this
is
this
would
be
the
manual
thing
right
you
can,
like.
I
click
the
the
plus
button
in
the
right
hand,
of
the
version
history
and
it's
like
title
it.
So
we
could
do
you
know
I
think,
we're
on
like
0.5
or
whatever
at
this
point,
but
we
could
like
do
that
and
then
you
could
get
the
release
notes
here.
So
that
makes
that
makes
a
lot
of
sense.
At
least
it's
a
manual
process
and
then
yeah.
C
A
I
think
there's
there's
some
merit,
especially
for
like
especially
for
the.
If
the
goal
is,
we
want
to
keep
the
design
assets
and
the
code
in
sync
in
versions.
There's
probably
some
merit
for
like
not
doing
entirely
automatic,
and
this
goes
the
same
for
the
code
where
it's
like.
I
don't
necessarily
want
to
say
that
whatever
it
looks
like
at
two
a.m,
pacific
on
thursday
is
what
we're
releasing
like.
A
I
think
that
having
sort
of
the
push
button
like
where
we
don't
have
to,
I
don't
want
to
go
in
and
change
all
the
things,
but
I
want
to
be
able
to
say,
like
okay
cool
release,
the
new
one,
let's
go
and
like
probably
same
thing
here,
where
you
know,
I
don't
think
we
want
like
a
strict
scheduler,
that's
like
get
it
in
before
2am
or
else
like
that's
part
of
the
version.
Now
I
think,
having
the
ability
to
to
have
human
intervention
and
say
like
yes,
we're
agreeing
this.
C
Yeah,
I
think
that's
a
good
point.
You
know
right
now
we're
because
it's
still
quite
internal
we're
not
really
reliant
on
too
much
feedback
from
external
teams
or
any
kind
of
contributions
just
yet.
However,
that
is
something
that
we
have
to
be
made,
be
able
to
scale
the
system
to
support
and-
and
once
that
happens,
that's
when
we're
kind
of
falling
into
the
realm
of
taking
a
hunch,
a
contribution
in
some
sort
of
a
digital
asset
along
with
code.
C
So
there
can
be
an
argument
made
for
certain
times
to
you
know
if,
if
it's
a
component
or
a
block,
let's
say
that's
very
early
on
in
its
life,
but
we
do
find
that
it
actually
has
a
value
for
whatever
it
is
some
sort
of
a
widget.
For
just
as
an
example,
we
can
have
the
design
asset
within
figma
before
it's
released
in
code,
and
we
can
add
notes.
C
You
know
we
can
control
the
library
different
ways
within
figma,
so
that
designers
aren't
too
hamstrungly
waiting
on
something
and
especially
if
it
already
exists,
or
if
they
see
it
in
another
mockup.
You
know
we
can.
We
can
have
that
degree
of
flexibility
to
support
and
not
hinder
because
then
we're
not
serving
a
positive
purpose
so
to
speak.