►
From YouTube: Package & Release ThinkBig #1
Description
Join the Release Management & Package team as we discuss Versioned Dependencies: https://about.gitlab.com/direction/versioned-dependencies/
https://gitlab.com/gitlab-org/gitlab/-/issues/215390
A
All
right,
so
I
think
last
week,
tim
reached
out
about
a
direction
page
called
allow
or
version
dependencies,
and
we
started
brainstorming,
some
jobs
to
be
done
between
the
release
and
package
stage,
and
we
created
this
issue.
Actually
tim
created
this
issue
and
I
added
some
some
thoughts
to
it.
But
tim
is
there
anything
that
you
want
to
add
to
that.
B
Yeah,
so
it
came
the.
I
think
there
was
three
sources
that
I
would
credit
for.
The
idea
for
this
one
would
be
nathan
opening
the
idea
for
adding
semantic
versioning
to
releases
that
was
kind
of
the
original
impetus
and
then
for
the
q1
product
okrs.
We
were
doing
competitive
analysis
of
some
of
our
like
our
competitive
products
for
package,
and
they
each
offer
a
similar
offering
to
this.
B
So
the
idea
that
you
can
distribute
release
bundles
to
an
arbitrary
amount
of
machines
and
that
you
may
want
to
include
packages
and
images,
and
then
shortly
after
that,
I
had
and
then
one
of
our
like
long
time,
enterprise
customers
reach
out
and
say:
do
you
offer
anything
like
this?
What
we
really
need-
and
their
use
case
is
a
little
special-
they
basically
need
to
take
a
release,
bundle
and
distribute
it
to
a
bunch
of
iot
devices
that
have
limited
internet
connectivity.
B
But
if
you
take
out
the
iot
and
limited
connectivity
still
the
idea
that
people
want
to
create
a
release,
bundle
and
then
they
want
to
include
immutable
images
and
packages
as
part
of
it,
and
then
they
want
to
distribute
that
to
other
machines.
That's
kind
of
the
use
case
that
I
heard
from
the
customer
and
from
at
least
what
I've
seen
from
our
competitors
as
well.
A
So,
on
the
releases
side,
we
have
a
lot
of
this
sort
of
already
kind
of
framed
out
on
the
releases
page
with
the
releases
tag
and
the
ability
to
add
asset
links.
I
think
the
parts
that
are
a
little
bit
trickier
are
around
supporting
something
like
the
packages
in
the
releases
page,
but
also
making
it
discoverable
for
those
who
have
to
consume
those
packages
or
binaries,
especially
if,
let's
say,
there's
a
version
that
they
have
this.
This
customer
has
they
want
people
to
use,
and
then
they
have
another
release.
A
That's
an
in-progress
version
that
people
can
build
on
top
of
that
they're
distributing,
but
they
want
to
have
an
immutable
piece
of
it.
So
we
don't
support
like
that,
once
you
link
something
to
a
release
asset
that
artifact
can
expire.
So
there
isn't
like
a
persistability
of
that
today.
So
that's
a
part
that
we
should
think
about
or
talk
about,
in
addition
to
just
expanding
any
release,
capabilities
to
support
other
package
features,
and
then
I
wanted.
B
A
Yeah,
so
that
that
could
be
one
way
to
solution
that
the
other
one
would
just
be
to
store
the
items
in
a
different
way,
so
that
people
can
access
them
and
they
don't
expire,
we're
kind
of
exploring
this
with
junit
reports
and
the
artifacts.
So
it's
like
it.
It's
just
changing
how
it's
stored,
so
it
doesn't
expire.
C
Okay,
we
have
from
the
package
side
when
we
talk
to
our
users,
there's
a
couple
different
reasons:
they
want
to
create
versions
of
packages
or
specific
images
that
can
expire
or
can't
move.
So
it
could
be
that
we
follow
on
that
same
logic
and
if
it's
part
of
a
release,
it
is
inherently
protected
and
then
it
just
stays
there
again
unless
the
maintainer
starts
to
get
involved.
A
A
I
think
today
we
do
have
customers
in
the
embedded
software
space
that
are
uploading,
an
external
link
to
their
releases,
page,
that
that's
too,
like
an
artifactory
or
two
even
a
container
or
package
registry,
and
they
have
that
release
published
for
people
to
then
consume
and
download.
So
this
is
something
that
customers
are
doing
today.
A
I
think
the
part
that
gets
a
little
weird
is
if
we
want
to
support
the
native
functionality
of
like
attaching
a
package
and
having
a
separate
section
inside
the
releases
page,
that's
something
that
we
have
as
an
open
issue
today
and
not
sure
if
we'd
want
to
start
delivering
against
that
to
create
better
visibility
between
packages
and
releases.
I.
B
Think
sorry,
just
to
clarify
what
you
are
saying
is
we
can
do
it
today.
It's
just
they
don't
get
any
distinction
that
it's
a
package
on
the
release
page,
I
think
that's,
okay
to
start
and
I'm
maybe
the
best.
The
fastest
thing
we
could
do
is
just
share
some
like
documentation
on
how
to
do
this
and
just
show
people
like
a
sample.
Workflow
of
we
have
an
image.
We
have
a
package
and
we
have
some
other
artifacts.
E
B
B
E
Yeah,
I
think
we
could
do
that.
I
don't
know
if,
if
that
would
make
the
most
sense
or
if,
if
we
already
had
like
a
bunch
of
releases
that
had
say
we're
already
using
semantic
version,
we
could
kind
of
just
read
all
the
lists
and
then
look
at
the
highest
one
and
increment
it.
That
way
like
we
wouldn't
necessarily
need
to
keep
a
variable
around.
For
that,
oh
that's,
cool,
but
at
the
end
effect
I
think
would
be
the
same
basically
a
way
to
have
kind
of
a
I'll
get.
B
A
A
So
this
is
something
that
we
can
create
like
a
blog
post
about
and
talk
about,
the
benefits
of
using
a
release,
tag
in
addition
to
linking
to
a
container
registry
or
package
registry
for
people
to
then
consume
that
as
an
asset
link.
I
think
that
you're
actually
right.
We
can
do
a
recording
and
have
that
be
a
consumable,
but
there's
also
something
to
to
like
connect
upstream
to,
like
other
other
other
pieces
of
gitlab,
to
showcase
this
functionality,
as
it's
not
very
discoverable.
C
I
don't
know
way
to
put
me
on
the
spot
there.
Mr
tim,
I
am
kind
of
thinking
from
the
other
direction
of
ways
that
we
could,
if
discoverability,
is
an
aspect
of
it
to
bring
it
into
the
package
ui
where
we
could
say.
If
you
look
up
a
package,
you
can
see
that
it's
attached
to
a
release
so
working
the
other
way
and
it
also
kind
of
ties
into
that.
It's
protected
and
here's.
Why
idea?
C
A
I
don't
really
like
the
idea
of
tabs
but
being
able
to
create
a
distinguished,
but
also
a
centralized
place
for
managing
all
the
release.
Artifacts
is
something
our
users
are
very
interested
in,
and
I
think
a
tab
would
allow
us
to
sort
of
consume
the
package
information
without
having
it
be
nested.
Inside
of
all
the
releases
stuff.
C
Just
a
question
because
I
I
don't
have
the
data
when
people
are
working
on
releases
and
you've
been
talking
to
customers.
How
many
of
these
package-related
artifacts
tend
to
be
tied
to
a
single
release?
Are
they
looking
at
one
specific
image
tag,
or
is
this
a
large
collection
of
different
objects
that
they
need
to
be
managing.
A
So
it's
a
wide
variety
and
it
depends
on
what
the
customer's
using
releases
for
so,
if
they're
using
releases
to
tag
a
continuous
delivery
life
cycle,
it
can
be
a
mult,
an
image,
that's
used
across
hundreds
and
hundreds
of
release,
tags
right
if
it's
a
monthly
cadence
that
they're
then
packaging.
All
of
these,
mrs
and
the
release
is
actually
a
container,
that's
representative,
but
not
actually
connected
to
contents
of
a
release.
A
So,
for
example,
they
may
associate
a
milestone
to
then
capture
the
mrs
and
issues,
but
that
tag
is
not
a
commit
tied
to
a
production
instance
or
production
code.
It's
an
it's
a
bucket.
That,
then,
is
a
relationship
of
all
the
stuff
that
could
be
representative
of
production
code
and
the
release.
Evidence
is
all
the
things
that
are
contained
within
that
issue
and
mr
and
that
bucket,
that
might
be
then
linked
to
an
external
image
that
contains
all
of
the
contents
of
that
release.
A
Does
that
make
sense,
so
it
would
be
a
single
package
that
is
then
stored
somewhere
externally
and
then
that's
what's
published
as
a
part
of
the
release
and
there's
some
some
places
in
between
two.
Where,
like
they
have
a
latest
version
that
their
customers,
their
internal
customers,
are
using
from
an
intersourcing
use
case,
but
then
they
have
a
release,
tag
that
says
upcoming
and
it
will
be
then
updated
with.
B
D
D
D
B
A
D
F
G
B
A
Yeah,
but
just
as
what
sean
was
saying,
we
kind
of
are
restricting
it
just
to
the
release
contents
that
people
are
uploading,
but
when,
when
I
think
about
that,
it's
flex
technically
it'd
probably
be
flexible
enough,
that
it
could
contain
any
given
package
that
people
are
uploading
to
the
release.
So
it
doesn't
really.
G
B
I
was
thinking
these
are
all
great
ideas
and
I
think
driving
cross-stage
usage
at
gitlab
is
really
valuable.
That's
according
to
the
growth
team,
so
I'm
wondering
how
let's
say
that
we
add
some
of
these
features.
What
metrics
could
we
use
to
say
at
the
end
of
the
day
that
we
were
successful
like
what
cross-stage
metrics
would
be
useful.
A
B
A
B
If
we
had
the
idea
of
protected
images
or
packages,
we
could
that
we
could
use
that
as
a
proxy.
We
could
say
that
when
an
image
or
a
package
is
protected
that
naturally
they're
being
tagged
for
a
release,
so
that
that
might
be
one
way
we
could
do
it
or
I
mean
in
general,
though,
what
we're
trying
to
do
is
increase
the
usage
of
the
release,
evidence
page
right
and
the
release
and
releases
in
general.
So
maybe
we
should
predict
that
should
be.
A
F
E
Hey
one
question
I
have:
it
depends
a
little
bit
to
how
we
implement
it,
because
if
we
are
thinking
that
this,
this
association
between
a
package
and
a
release
would
be
something
that's
automatic,
or
maybe
I
should
say
if
it's
not
automatic,
if
it's
something
that
they
have
to
explicitly
do.
That
would
be
an
easy
measure
to
track
just
how
many
releases
are
associated
with
the
package
or
vice
versa.
E
E
There
is
there's
a
couple
libraries
out
there
that
are
fairly
popular,
that
will
kind
of
automate
a
lot
of
your
releasing
especially
with
npm
packages.
I
know
so
they'll
increment
versions
based
on
commit
messages
and
automatically
publish
them,
and
so
then
I
I
haven't
played
around
with
them
enough
to
know
how
they
would
tie
into.
E
G
E
Awesome,
I
just
put
that
in
the
chat.
I
think
that's
the
one,
I'm
I'm
thinking
of
semantic
release
and
the
idea
is
that
you,
you
commit
a
change
yeah!
You
in
your
commit
message.
You
say
something
like
feature
like
you
have
little
tags
that
you
include
in
when
you're
coding
and
actually
make
the
commit
and
then
it
will
go
through
and
based
on
those
commit
messages,
publish
them
to
npm
or
or
do
other
automation
like
that.
A
A
Okay,
we
have
a
couple
of
other
jobs
to
be
done
that
we
were
flirting
with
as
a
part
of
this
functionality.
The
second
one
is
when
I
create
different
versions
of
artifacts.
I
want
those
to
be
stored
in
a
central
and
mutable
place
for
easy
access
and
version
control,
so
devices
and
users
can
consume
the
latest
artifacts
and
release
bundles.
A
So
this
sort
of
ties
back
to
nathan
what
you're
saying
about
automatically
incrementing
versions
and
making
that
easier.
If
we
have
that
in
the
releases
page,
that
would
be
a
central
location,
but
I
think
we
need
to
solve
for
that
cross-linking
of
how
many
like.
If
people
are
storing
items
in
a
package
and
where
we
want
that
to
be.
G
G
So
we
currently
support
support.
You
know
assets
that
are
externally
stored,
for
example
in
an
s3
bucket,
and
you
know
at
some
future
point
we'll
have
our
own
packet
registry
or
private
registry
or
wherever
it's
going
to
look
to
store
those
assets.
But
are
we
interested
in
everything
that's
on
that
release
page,
whether
it's
inside
of
the
gitlab
package
registry
or
whether
it's
some
external
resource,
just
you
know,
doesn't
matter
if
it's
on
the
release
page?
B
B
B
So
it
sounds
like
jackie,
would
you
say
this
is
like
an
appropriate
steps
to
be
had
one.
It
would
be
like
a
some
documentation
and
or
a
blog
post,
potentially
with
a
customer
demonstrating
how
to
do
this
from
the
package
side.
What
we
need
to
work
on
is
a
way
of
protecting
packages
and
images
from
to
make
them
immutable.
Once
they've
been
identified
as
such,
we
also
we
we
we
want
to
get
create
a
generic
package
manager,
that's
on
our
roadmap,
by
the
way
in
like
1304.
B
B
B
And
then,
from
the
release
side,
we
want
a
way
to
create
and
add
on
to
semantic
versions
for
releases,
and
then
we
want
a
way
to
make
those
once
that
they,
once
the
semantic
version
has
been
created
and
released,
that's
some
way
of
protecting
it,
so
that
it
it
also
can
be
immutable
yes
and
in
terms
of
distribution
of
releases.
That
can
happen
naturally,
because
I
think
sean
was
mentioning
it's
on
s3,
so
it's
already
distributed
and
and
easy
to
graph.
Okay,.
E
F
A
Or
customers
are
doing
that
today,
as
is
so
they're
using
an
asset
link.
What
I
was
thinking
is
creating
a
separate
section
that
is
dedicated
to
packages
that
would
probably
reuse
the
same
functionality,
but
it's
to
improve
the
visibility
of
package
linking
and
then,
if
there's
other
things
that
we
would
want
to
like
automatically
do
from
the
ammo
file
like
this
package
is
tied
to
this
release,
then
we'd
be
able
to
populate
that
with
the
release.
Cli.
A
So
the
the
intent
here
is,
things
can
get
lost
in
the
assets
section.
So,
for
example,
let's
let
me
pull
up.
Let
me
share
my
screen
real
quick.
So
if
we
look
at
the
runner
project,
for
example,
they
have
lots
of
stuff
in
their
asset
links
and
as
a
result,
it's
not
describable.
It's
not
easy
to
to
like.
A
A
A
G
I
can
I
completely
agree
with
that
jackie,
particularly
as
we
as
you
as
an
example,
you
pointed
out
when
there's
many
many
different
binaries.
Is
it
something
we
could
to?
We
could
progress
towards
because
you
can
see,
I
mean
you
can
have
subcategories
and
I
mean
there
could
be
all
sorts
of
categorizations
you
could
have
labels.
G
A
G
A
So
we
have
to
be
kind
of
choosy
about
what's
the
important
information
that
users
want
and
if
we
compare
it
to
other
tools
that
are
publishing
releases,
binaries,
release,
notes,
tag,
identification
and
audit
compliance.
Information
are
the
the
four
classifications
of
information.
So
there's
just
we
just
have
to
be
mindful
about
all
the
things
that
we're
adding.
G
G
A
So
there's
in
the
validation
that
we
did
hayan
and
I
did
around
the
view
page
and
what
people
are
looking
to
see,
they
want
to
see
first
the
contents
of
the
release,
which
is
why
the
release
progress
view
is
at
the
top
from
like
an
issues
and
mrs
included
in
the
release.
The
second
that
they
want
to
see
is
things
that
are
inextricably
tied
to
that
release
that
others
are
going
to
consume.
A
G
A
So
I
feel
I
feel
pretty
strongly
about
not
having
just
an
expansive
scroll
of
a
releases
page.
We
have
to
think
very
thoughtfully
about
how
do
we
generate
traction
to
link
off
of
the
releases
page
into
other
parts
of
gitlab,
while
still
containing
the
relevant
information
on
the
releases
page,
I
mean
making
it
really
easy
to
see
at
a
glance
like
well.
What's
in
this
release,
right.
C
I'm
just
curious
if
on
the
releases
page,
if
they
have
a
large
number
of
images
and
packages
in
different
categories
of
things,
if
we
could
actually
surface
on
that
overall
scrolling
page
just
it
contains
13
packages,
two
images
and
13
auxiliary
artifacts,
and
then
you
can
create
a
sub
page
where,
if
I'm
a
user,
that
actually
cares
about
the
packages.
Because
I'm
an
engineer
more
likely,
I
can
go
there.
If
I
need
the
container
because
I'm
on
deployment,
I
can
just
go
to
that
section
and
start
kind
of
walling
off
the
different
pieces.
A
So
you
are
you're
you're
totally
in
the
same
in
our
heads,
you're
reading
exactly
what
what
we're
seeing
too.
So
thank
you
for
being
there
with
me
and
that's
really
affirming
to
hear
somebody
else
say
those
things
as
well,
so
there
we're
expecting
to
create
a
fork
between
the
project
landing
page
and
the
release
version
view
page.
A
D
E
E
A
And
that's
what
we
really
need
to
do,
because
today,
they're
just
duplication
and
when
you
have
over
for
the
customers
who
are
doing
continuous
delivery
and
they're
tagging
each
commit
with
the
release
tag,
for
example,
and
then
they
have
like
a
batch
job
that
they
do
external
to
the
system
to
aggregate
all
those
release,
tags
that
can
be
really
onerous
to
look
at
the
releases.
Page.
People
probably
are
not
going
to
it
as
much
as
they
would
want
to.
In
those
cases.
A
Yeah
and
that's
exactly
the
mvc
that
I
was
trying
to
go
after
with
that
issue
was
to
allow
us
to
not
only
specify
the
run
book,
because
the
run
book
is
one
asset.
That's
really
important
to
the
release
manager
so
to
be
able
to
discover
that
is
important,
but
you're.
Absolutely
right,
like
packages
or
arbitrary
links,
is
really
important.
A
C
Just
to
note,
if
you're
starting
to
categorize
things
when
we've
been
talking
to
users
and
I'm
sure,
sounds
familiar
to
a
lot
of
people,
but
images
and
packages
are
two
very
different
ideas,
so
I
may
suggest
that
they
have
their
own
individual
categories
and
even
from
there
I
don't
know
how
valuable
it'd
be.
I
would
want
to
check
with
your
users
about
different
package
types,
because
sometimes
I
can
have
a
difference
in
how
they're
interpreting
things.
C
C
A
E
Sounds
good
one
question
about
the
package
if
we
would
link
to
a
package,
I
am
not
super
familiar
with.
I
don't
know
if
we've
changed
the
package
screen
lately
but
like
is
there
a
a
dedicated
page
for
a
specific
version
of
a
package,
or
is
it
just
a
package
with
a
list
of
alt
versions
like
what's
what
would
be
the
best
way
to
link
to
it.
C
Yeah
right
now,
each
package
version
has
its
own
page
we're
working
on
creating
a
tab
that
is
the
you're
looking
at
this
version
of
the
package
and
then
here's
all
of
the
other
versions
of
that
package.
But
as
it
stands
now
and
tim
correct
me
if
I'm
wrong,
but
you
can
link
directly
to
a
package
of
a
specific
version
and
it
has
its
own
dedicated
page
and
all
of
its
details
are
associated
there.
B
B
I
had
to
try
to
explain
why
we
were
doing
that
in
a
release
post.
It's
actually
very
complicated,
to
explain
nesting
in
words
in
two
sentences
that
anyone
who's
never
read
anything
could
understand.
I
was
like
going
back
to
atomic
definitions.
I
was
like
a
package
is
published
with
a
name
and
a
version.
B
A
E
A
B
A
A
E
One
final
question
too:
just
about
the
link
types
I
just
trying
to
think
about.
If
we
I
just
imagine
a
future
where,
like
we
could
really
have
anything
associated
to
a
really
like,
we
could
have
a
ux
category
like
ux
designs,
or
I
don't
know
like.
Does
it
make
sense
to
have
this
kind
of
finite
list
of
of
things
like?
Are
we
just
going
to
be
constantly
adding
new
new
items
to
this
list
and,
what's
the
actual
end
result
like
what
does
it
mean
when
someone
associates
something
as
a
package
like
so.
A
I
think
it's
a
good
call
out.
I
in
my
past
life,
I
owned
social
media
postings
and
we
had
this
one
list
that
ended
up
being
a
thousand
categories
long
and
it
lost
its
value
of
being
a
pick
list,
as
the
value
in
a
pick
list
is
being
able
to
track
your
users
behaviors
and
see
what
they're
actually
associating
to
their
releases.
A
If
you
end
up
seeing
a
bunch
of
others
as
a
link
and
they're
only
looking
at
linking
others
to
the
release,
then
maybe
adding
a
configuration
option
to
people
to
allow
people
to
expand
asset
types
by
themselves
is
actually
the
best
user
experience
we
can
offer.
But
since
we're
not
tracking
it
today-
and
we
don't
really
know
how
people
are
wanting
to
adopt
releases,
this
is
an
easy
hack
to
kind
of
track
what
things
people
are
associating
in
a
clean
way.
E
A
Makes
it
really
discoverable
for
people
consuming
their
releases?
So
if
I
want
to
see
my
packages
as
an
asset
type,
instead
of
creating
a
new
section,
this
was
the
mvc.
So
instead
of
spending
a
lot
of
time,
creating
new
sections
allowing
them
to
make
their
asset
lists
more
discoverable,
an
asset
type,
would
help
that
part.
So
this
was
like
the
first
iteration
to
adding
more
sections
to
the
releases
page.
Does
that
make
sense?
A
A
Yet
because
we
talked
to,
we
talked
like
you
know
six
customers
a
week
and
asked
them
like
what
kinds
of
things
do
you
want
to
see
on
your
releases
page
and
they're,
like
you
know
things
people
use
and
then,
of
course
you
can
ask
them
a
bunch
of
questions,
but
it
doesn't
give
you
an
aggregate
and
when
people
are
forced
to
choose
a
binary
or
category
they'll
pick
the
one
that
most
matches
their
need.
First
and
then
they'll
rely
on
other
as
like
a
a
catch-all.
A
G
So
we
could
start
with
a
couple
of
pre-populated
entries
in
the
list
and
then
allow
them
to
do
what
they
want,
and
so
so
that
does
that
mean
then,
on
the
on
the
main
page,
the
list
page,
we
would
just
have
the
categories
and
then
you
know
a
number
against
each
one.
And
then
you,
when
you
went
to
the
detail,
page
you'd,
see
the
contents
of
those
categories
or
lists
or
whatever
we're
going
to
call
them.
A
Menu
and
then
in
the
future,
counters
might
be
what
we
want,
or
we
use
those
asset
types
on
the
view
pages
to
populate
the
counters
on
the
project
landing
page.
But
my
first
priority
is
to
make
the
asset
list
more
usable,
so
people
will
want
to
use
it
right.
So
I
think
for
sure
that
can
definitely
be
how
we
systematically
update
the
project
overview
page
for
releases.
But
for
now
it's
just
a
drop
down
menu.
E
A
E
If
we
just
associate
a
package
with
the
release
through
a
link,
that's
not
as
strong
of
a
of
a
connection,
and
I
don't
know
if,
for
example,
if
the
package
probably
wouldn't
be
able
to
take
advantage
of
seeing
that
association
back
to
the
release,
which
I
think
is
something
you
guys
are
interested
in.
If
I'm
not
mistaken,
but
so
I
don't
know
if
we
want
to
consider
implementing
a
package
through
a
more
like
a
system
level
association.
C
So,
like
nathan
was
saying
you
can
go
back
to
the
package
page
and
look
at
this
version
of
the
package,
and
it
says
it's
attached
to
this
release
and
that's
makes
it
more
discoverable
both
ways
and
then
you
can
see
that
auxiliary
section
of
this
never
came
from
gitlab
and
you
just
uploaded
it,
because
it's
a
video
game,
video,
playthrough
and
that
didn't
come
from
gitlab
but
still
attached
to
the
release.
So
that
becomes
like
the
other
section,
and
then
you
can
start
breaking
that.
Apart
more
later,.
A
This
is
the
dream
team
right
here
and
I'm
going
to
ping
you
on
that
issue
for
specify
asset
types
and,
if
there's
a
resource
that
you
can
link
there.
So
I
can
update
the
description
and
issue
of
like
if
it's
built
by
gitlab,
what
that
means
and
allowing
users
to
populate
that
drop
down
menu
for
that
and
like
the
mvc,
is
just
to
provide
the
drop
down
menu
and
maybe,
if
it's
built
by
git,
lab
there's
other
things
that
are
just
going
to
come
by
that
association.
C
Can
I
ask
a
I'm
not
an
engineer,
so
I
don't
know
how
easy
this
is.
But
gitlab
does
this
really
cool
thing
where,
if
I
paste
a
link
to
an
epic
in
a
in
a
comment
box,
it'll
automatically
like
shrink
it
down
to
the
epic
name
and
it
links
directly,
there
is
there
a
way
that
we
can
continue
to
have
the
same
experience
where
users
are
adding
links
to
the
package,
whether
it's
in
the
gitlab
registry
or
not,
and
then
later,
because
we
have
all
that
data.
C
C
Yeah
something
like
that,
I'm
definitely
not
the
technical
person,
but
if
that's
the
experience
you're
going
through
anyway
is
I'm
going
to
add
a
link
to
an
asset,
that's
somewhere
else,
and
then
that
keeps
with
the
similar
user
experience
and
then
later
we
as
gitlab
start
to
be
a
bit
smarter
and
recognize
that
that
link
linked
back
to
a
gitlab
package
registry
and
create
that
more
naturally
for
the
user.
Because
then
it's
a
surprise
of
like
ta-da.
C
A
G
G
A
E
A
E
So,
maybe
that
we
need
to
look
into
that
and
see
what
that's
doing
but
ian.
To
answer
your
question,
I
think
I
think
that
is
a
a
good
option
and
now
that
you
say
that
we
do
already
have
precedence
for
that,
because
we
already
can
like
parse
a
an
internal,
url
and
kind
of
understand
what
it
means.
So
maybe
that
is
a
good
way
to
go,
because
that
could
be
a
yeah.
If
we
add
it
in
the
future,
we
can
we
already
kind
of
can
infer
what
they
have
which
packages
they
have
associated.
A
E
A
A
E
G
A
Okay,
so
tim
I'll,
open
up
that
blog
post,
mr
for
us
to
partner
on
that
workflow
and
I'll
reach
out
to
the
customer
on
if
they'd
be
willing
to
kind
of
talk
through
how
they're
using
releases
to
distribute
their
packages
and
then
I'll
look
out
for
your
version.
Dependencies
direction,
page
update
and
contribute
to
that
and
I'll
create
a
couple
of
issues
from
this
call
and
we
can
begin
implementing
some
of
these
things.
B
B
I
think
that
can
creating
additional
multi-stage
usage
is
really
valuable
and
I
think
package
and
release
are
naturally
connected.
So
I
think
I
think
it
would
be
helpful,
but
if
it
seems
like
too
much
synchronous
meeting
or
if
it
seems
like
a
hassle,
we
could
do
it
asynchronously,
but
I
I
definitely
enjoyed
this
and
I
think
it's
good
for
us
to
think
this
way.
E
A
Perfect,
well,
we
have
two
mvcs
to
implement.
I
think
the
asset
types
and
the
generic
package
registry,
I
think,
are
the
two
from
the
releases
side
that
will
move
this
connection
forward
in
the
near
term
and
then
longer
term
is
how
do
we
create
a
more
natural
native
experience
between
packages
inside
the
releases
page?
I
think
it's
like
the
long-term
view,
based
on
what
I
heard.
E
Here
one
question
I
have
about
that
generic
package
registry.
I
think,
when,
from
our
point
of
view,
isn't
that
we're
just
uploading
we're
just
adding
the
ability
to
upload
assets
like
an
actual
blob
right
to
a
release
so
on
the
package
side?
Is
it
more
about
tracking
dependencies
between
between
blobs,
like
is
that
kind
of
the
idea
of
the
generic
package
manager?
Is
it's
is
it's
more
about
dependencies,
or
is
it
still
just
about
uploading
blobs?
I
think
it's
just
still
about
uploading,
yeah,
okay,.
E
In
my
head
that
the
real
value
of
a
package
manager
is
that
it
manages
all
the
dependencies
of
of
your
like
you
of
your
blobs
like
it'll,
you
don't
have
to
worry
about
managing
all
that.
So
I
maybe
I
don't
quite
understand
the
scope
of
that
generic
package
registry,
but
it
seems
like
it
might
be
different
than
what
we're
trying
to
do.
B
G
H
G
A
C
A
A
I
like
that,
I
don't
want
to
I
think.
If
it's
scoped,
then
it
replaces
the
other
one
though
right,
so
it
can't.
There
could
never
be
two
think
bigs.
You
can
only
have
one
thing
thick
snooty.
You
don't
want
to
think
too
big,
too
big
y'all
too
big
all
right.
Well,
sorry
for
running
you
all
over
we'll
we'll
talk
soon!
This
was
great.
Thank
you
for
your
time.