►
From YouTube: Group Releases
A
A
C
Already
so
I
wanted
to
start
a
discussion
on
a
thing
called
group
releases,
so
in
the
first
MVC
I
had
this
thought
that
we
would
just
enable
users
in
their
planning
releases
by
leveraging
group
milestones.
So
that's
what
we
have
scheduled
in
the
next
couple
of
milestones
is
to
support
the
association
of
a
project
release
tag
to
a
group
milestone,
but
then
Nathan,
you
brought
up
this
greater
question
archetype
about
actually
having
an
object
at
the
group
level.
That
is
a
release.
C
I
would
love
to
hear
a
little
bit
more
about
that
I
created
an
epic
and
high
on
it.
Added
a
bunch
of
sub
issues
based
off
of
supporting
releases
association
to
a
group
milestone
but
I
think
in
theory.
We
could
break
the
association
of
a
tag
from
a
project
release
and
move
it
up
to
the
group
level
and
have
that
object
shared,
but
would
love
to
hear
more
about
what
you
were
thinking.
D
D
D
C
B
B
C
Well,
I
one
thing
to
say
about
about
the
Burton:
the
fracture
of
a
tag
from
a
release:
yep,
so
Nathan.
All
Shawn
was
just
talking
about
his
two
cents
on
it
being
a
good
feature.
We're
supporting
of
sharing
this
object
across
multiple
projects.
You
compa
lists
things
like
multi-project
pipelines,
right,
there's
a
lot
of
archetypes
that
show
we
need
to
do
things
across
multiple
projects
and
what
we
call
it
at
gitlab
is
supporting
at
the
group
level.
But
when
I
did
this
huge
validation
around
multi-project
things,
people
are
testing
across
projects.
C
B
B
D
So
my
my
one
thought
is:
if
this
is
something
we
wanted
to
support
like
a
group
level
release
which
I
kind
of
think
it
could
be
a
neat
idea,
I
think
Sean,
you'd
made
a
comment
about
like
being
able
to
coordinate
releases
across
projects
is
something
yeah
that
would
make
sense,
which
it
makes
sense
to
me
like
even
at
gate
lab.
We
have
a
lot
of
different
projects
like
the
runner
and
the
yeah
I'd
be
good
to
be
able
to
sync
all
those
into
one
cadence.
D
If
we
did
want
to
do
something
like
that,
maybe
it
would
make
sense
just
to
slightly
modify
the
release
page
for
the
group
page
and
allow
you
to
associate
multiple
tags
with
a
single
release,
specifically
one
tag
per
project,
and
they
kind
of
like
snapshot
across
several
projects
and
that
that
group
release
could
kind
of
be
that
that
way
to
sync
it
up.
I
love.
D
C
I
I,
remember
Sean.
You
made
a
comment
about
this
idea
that
I
had
about
calling
it
a
version
or
something
different,
so
like
creating
a
fracture
of
what
we
call
a
release
candidate
at
the
project
level
and
what
we
call
something
at
the
group.
So
when
we
look
at
a
release
manager,
they
are
often
coordinating
an
end
production
state
for
a
customer
they're,
not
necessarily
looking
at
like
one
micro
service
being
promoted
to
an
environment.
B
C
B
So
there's
a
few
things,
there's
a
few
things
so
I'm
getting
I'm
thinking
through
what
would
be
required
at
the
back
end
and
there
will
be
probably
quite
a
bit,
but
that's
that's
not
you
know
any
reason
to
not
do
this.
Of
course.
So
you
know
in
our
current
state
you
know,
release
is,
is
the
same
thing
as
a
tag
or
there,
but
not
the
same
thing,
but
they
are.
They
are
connected
one
to
one,
so
we
would
have
to
potentially
break
that
apart.
B
Well,
that's
what,
let's,
let's
call
them
project
release
and
group
release,
even
though
I
know
we're
not
going
to
actually
call
them
those
two
different
things
just
just
to
differentiate,
because
so
you
mentioned
version
Chucky
and
so
I
think
you
know,
maybe
we
would
have
to
hurt,
but
a
different
person's
two
ways
of
doing
it
right.
We
can
split
the
release,
object
out
of
project
altogether
and
then
associate
it
back
to
project
and
associated
to
group.
That's
one
way
of
doing
it
or
we
could
have
this
kind
of.
B
I
think
that
would
probably
be
the
least
painful
way
forward,
or
although
I
mean
we
I
think,
which
probably
should
do
a
research
issue
on
this,
because
if
we
look
at
the
example
of
get
layered,
so
you
know
we
release
for
thirteen
point
two,
for
example,
but
in
fact
what
that
actually
refers
to
is
division
of
the
rails
application.
We
reverse.
The
versions
of
the
other
applications
are
all
different
version
numbers,
and
maybe
they
don't
even
get
a
bump
in
a
particular
release.
They
might
just.
B
You
know
it's
possible
that
nothing
happens
to
one
other
component.
You
know
the
release
the
release,
the
CLR,
for
example.
Maybe
we
don't
do
anything
to
it
in
the
next
version,
and
so
so
then
you
know,
then
you
need
some
way
to
have
this
overarching
view.
This
is
13.2,
which
happens
to
be
thirteen
point
two
of
the
rails,
and
it's
also
whatever
other
versions
or
the
other
components
which.
C
D
C
C
We
don't
need
to
duplicate
the
planning
functionality
because
we're
going
to
seat
planning
functionality
in
the
milestones,
but
then
there's
this
actual
say
that
we
have
a
machine,
that's
triggering
the
releases
and
we
want
to
create
like
a
cascade
of
events
after
that
and
the
animal
file
with
automation
tags
are
going
to
be
more
useful
than
the
milestones,
because
those
are
like
actions
of
releases
rather
than
like
a
run
book
like
I'm
thinking,
then
a
planning
series
right,
so
planning
will
be
milestones.
Everything
else
will
be.
You
know,
like
any
actions.
C
C
B
C
Would
say
every
time
I
validated
this
with
the
customer,
they
are
most
likely
calling
a
released
candidate,
a
deployment
and
they
would
use
a
tag
to
indicate
a
pre
release
and
then
they
would
go
through
a
validation
for
production
release
on
that
tag
and
convert
it
to
a
release
tag.
So
that's
like
that's
the
most
common
use
case.
I've
heard
people
using,
and
this
is
even
people
who
are
using
github,
not
just
get
lab,
so
they
have
a
a
release
version
that
they're
considering
they
go
through
some
validation
sonot.
B
So
so,
if
we
were,
you
know
coding
all
this
from
from
now
and
we
hadn't
got
their
history
in
our
application.
Does
it
make
more
sense,
then,
to
just
basically
have
an
independent
release,
object
that
is
connected
to
a
group
or
to
a
to
a
project,
or
do
we
want
to
have
two
separate
objects?
But
one
of
the
group
live
one
of
the
release
level,
sorry
about
the
project
level,
so.
C
Here's
what
my
initial
gut
reaction
is
I
would
love
them
to
be
connected
and
tethered
together
somehow
and
a
way
that,
let's
say
we
have
a
project
release
and
a
user
is
creating
that
project
release
and
then
all
of
a
sudden
they
realize
they
have
micro-services
or
a
mobile
app
that
they
want
to
associate
to
that
particular
release
version.
Then
they
would
want
to
potentially
promote
that
release
at
the
project
level
to
a
group
to
contain
all
of
these
ancillary
functionalities
that
will
be
released
to
production.
At
the
same
time,.
B
C
C
Labels
like
project
to
group
labels
I,
could
see
them
going
into
the
application
looking
at
their
project
page
and
being
like.
Oh
this
web
app
is
actually
going
to
get
released
to
our
customers
alongside
a
mobile
app
alongside
microservices
updates,
alongside
other
applications.
So
I
want
to
promote
this.
C
If
people
think
that
technically
these
can
be
separate
and
they
don't
have
to
live
in
the
same
worlds
or
tables
I
just
wanted
to
give
you
a
use
case
where
I
could
see.
We
want
them
to
be
related
so
that
we
can
create
like
an
escalation
path
and
if
they're
not
related,
then
there
couldn't
be
an
escalation
path,
because
they're,
two
separate
objects,
I
think.
C
C
B
B
If
we
follow
that
model,
then
we
do
have
two
objects.
We
have
a
group
level,
but
then
we
have
a
path
to
push
it
up
and
and
everything
associates
with
it.
All
the
way
out
seems
like
fun,
but
at
the
event,
but
there
will
be
there
will
be
code,
but
I
guess
we
do
know
as
a
prerequisite
break
out
the
tag
right.
C
So,
for
example,
the
use
case
that
I'm
that
I've,
that
I've
discovered,
because
we
have
limitations
with
our
relationships
to
binaries
and
relationships
to
assets,
is
that
users
are
publishing
a
release
off
of
a
commit
from
the
API.
That
says,
generate
this
release
tag,
and
then
they
link
an
asset
to
an
external
repository
or
to
an
external
package
manager
or
even
to
our
package
manager.
Saying
this
is
the
version
you
should
be
consuming
off
of
infrastructures
code
or,
if
you're,
a
software
development
team.
This
is
the,
but
this
is
the
build
we
want.
C
C
If
we
break
this
relationship
in
totality
I
feel
like
we
would
create
confusion,
people
would
create
releases
without
relationships
to
the
code,
so
I
I
do
firmly
believe
that
there's
the
multi-select
is
probably
a
better
option,
but
then
we
have
this
whole,
like
upcoming
release
thing
that
we
we
need
a
support.
So
maybe
there's
got
to
be
a
yeah,
because.
B
C
D
The
only
the
only
use
case
I
can
think
of
that
you
wouldn't
want
a
tag.
Associate
is
upcoming
releases
other
than
that
I
think
it.
It
always
makes
sense
to
have
a
tag
associated,
but
that
being
said,
we
could
we
could
break
on
a
technical
side.
We
could
break
that
requirement,
but
then
threat
in
the
application
itself.
We
could
always
require
it,
as
part
of
our
workflows,
so
does
necessarily
mean
that
we
would
allow
people
to
create
a
release
without
it
without
a
tag,
even
if
in
the
backend
it
was
that
relationship
was
broken
because.
B
C
B
C
C
B
C
Maybe
there's
some
other
things
that
we
can
signal
inside
the
you
Aria
that
says
it
still
needs
a
tag
or
like
warning.
This
doesn't
have
a
tag
on
it
like
maybe
there's
something
that
we
can.
The
call
to
action
is
if
it
has,
if
it's
not
coming
release,
it
needs
to
have
eventually
have
a
tag
on
it,
and
maybe
there's
rules
that
we
can
create.
That
say:
hey
delete
this
release
after
30
days,
if
there's
no
tag
associated
to
it
or
whatever
date
frame
makes
sense.
A
A
B
A
C
I
remember
whenever
I
first
joined,
Jason
and
I
had
this
conversation
about
upcoming
releases
and
as
somebody
who
used
to
orchestrate
releases
across
multiple
teams
and
projects,
I
know
for
a
fact
that,
having
a
tool
that
allows
you
to
kind
of
forecast
or
contain
all
of
your
objects
into
one
place
is
helpful.
You
know
and
then
being
able
to
later
associate
what
your
production
state
is
is
exactly
what
CBO
Labs
lets
you
do
right.
B
C
C
B
B
D
But
also
if,
if
the
goal
is
just
have
upcoming
releases,
that's
kind
of
the
ideas,
a
future
release,
we
could
enforce
that
it.
You
have
to
have
a
release
date
to
set,
and
then
that
allows
you
to
create
a
release
without
a
tag
and
then
maybe,
if
that
date
passes,
then
they
don't
show
up
on
the
releases.
Pagers
I,
don't
know
we
could
do
something
with
that
release
date,
because
the
idea
is
that
these
are
being
released
in
the
future.
Like.
D
B
C
C
The
release
dot
attribute
is
your
Nate
yeah,
and
we
can't
we
can't
edit
that
in
the
UI,
so
it's
a
little
undiscoverable
right
now.
So
that's
probably
why
we
don't
see
like
thousands
of
upcoming
releases,
but
that's
like
the
minute
that
we
allow.
We
expose
that
to
the
front
end.
I
could,
if
we
choose
to
do
that,
I
can
see
a
bunch
of
like
again
an
orphan
releases
just
being
creative.
B
C
D
The
the
one
thing
I
was
thinking
is
that
I
can
see
a
use
case
for
having
an
upcoming
release
without
a
definite
release.
Date
I'm
just
thinking
of
like
even
the
library
we
use
view.
It's
not
like
our
front-end
framework.
We
use
there's
another
version
coming
out
view,
3
and
so
they've
had
they've
been
announcing
it
and
talking
about
it
for
a
long
time,
but
there's
no
like
set
release
date
on
it
and
I
could
see
that
being
kind
of
a
common
thing
where
we're
releasing
this
sometime
in
the
future.
D
D
C
D
C
Here's
the
other
use
case
that
we
kind
of
neglect.
When
we
talk
about
this
stuff,
we
don't,
we
often
think
about
the
SAS
world,
but
like
a
really
big
consumer
of
our
product
is
embedded
and
inner
sourcing.
So
when
we
look
at
those
two
use
cases,
they
may
have
like
a
radio
in
our
V,
always
consumed
version
3
and
that
version
3
will
always
be
alive
and
in
in
perpetuity,
because
it's
a
perpetual
license
right.
People
go
and
consume
it
download
it
and
they
may
never
update
version
3.
C
C
B
B
C
C
To
say,
like
my
Raspberry
Pi
is
running
off
of
a
really
old
git
lab
version,
because
I
have
a
bunch
of
stuff
with
my
3d
printer
that
it's
doing
and
if
I
break
that,
then
my
3d
printer
won't
work.
So
I
have
like
a
really
old
version.
That's
still
true,
still
being
supported
if
I
get
lab
and
it's
still
good,
even
though
like
in
our
world,
we
want
people
to
be
on
the
latest
version
right.
Yes,.
B
C
Like
this
is
where
the
group
page,
you
know
if
we
have
a
really
spun
--dl,
which
might
have
a
bunch
of
things
like
this-
is
a
declared
version
right
now
get
lap
has
milestones
which
indicate
versions
but
nobody's
calling
it
like.
We
call
it
that,
but
nobody
says
it
in
our
documentation
is
like
this
is
a
version
right.
B
C
C
Maybe
that's
a
badge
that
we
add
supported
version.
That's
could
be
a
new
feature,
but
what
what
we,
where
this
is
going
just
to
restate?
What
I
would
why
we
went
down
this
rabbit
hole
is
we're
talking
about
expiry
of
expiring
of
releases
and
if
an
upcoming
release
doesn't
have
a
declared
date
or
a
tag
on
it.
What
to
do
with
it
and
I
think
that
if
it's
an
upcoming
release
with
no
tag,
then
it
should
get
deleted.
C
B
C
A
A
B
C
B
C
This
isn't
a
used
case
in
today's
world
right
because
if
they
have
the
automatic
release
so
in
the
future,
if
we
just
had
to
fracture
it
upcoming
releases
with
no
tag
will
expire
after
30
days
and
get
moved
to
expired
releases.
Okay,
just
I'll
create
that
issue.
If
we
choose
to
break
like
I,
do
I'm
worried
about
this
whole
breaking
of
tags
and
releases
I'm
worried.
C
B
Well,
just
a
couple
of
questions
around
that
right
so
because
the
part
of
a
reason
to
do
that
would
be
this.
You
know
group
releases,
but
if,
if
we
break
it
say
at
the
moment
the
tag
is
just
a
field
on
the
release
table
and
it's
more
or
less,
but
it's
more
or
less
essentially
used
as
the
as
the
primary
cave.
No,
it's
not
actually,
but
if
we
broke
it
are
we
saying
that
we
can
have
more
than
one
tags
were
given
release
only.
B
B
B
C
Maybe
they
are
continuously
delivering,
they
create
a
release
per
deployment
on
their
project
and
they
want
to
declare
a
major
version
so
say
that
they
have
five
release,
tags
and
project
a
and
each
of
those
are
updates
to
different
micro-services
or
whatever,
and
they
want
to
declare.
This
is
project
a
monthly
release
and
it
contains
these
five
release
tags.
But.
C
D
The
one
thing
that
is
nice
about
having
a
single
tag
per
project
would
be
like,
for
example,
when
we
have
those
assets
that
we
automatically
download
those
sources.
If
we
had
like-
let's
say
five
tags
from
one
project,
I
don't
know
how
right
now,
those
are
dripping
off
the
tag
like
you
download
the
code
at
that
snapshot.
So
if
you
have
five
snapshots
suddenly
I
guess
you
could
have
each
version
of
that
as
a
download.
But
what.
C
D
C
D
C
D
C
But
when
we
start
to
uplevel
it
at
the
group
level,
they're
saying
that
this
is
my
defector
release
now
at
this
group,
so
each
individual
projects
release
assets
should
actually
be
like
bundled
and
reconciled
so
that
when
they
download
that
asset
at
the
group
level,
it's
the
changes
for
all
the
sub
projects.
Right,
yeah.
C
C
D
Yeah
that
could
be
some
another
way
to
track
upcoming
releases
because
you
can
have
your
pre-release
branch
and
then
the
nice
thing
is.
Is
that
automatically
with
like
branches
move
as
people
update
them?
So
then
your
release
would
always
point
to
kind
of
the
latest
version
of
that
branch,
and
so
that
might
be
a
way
of
kind
of
implementing
upcoming
without
completely
disconnecting
releases
from
the
source,
so
good
thoughts.
So.
B
D
B
D
B
B
D
We
might
be
careful
again
go
back
to
naming
about
release
candidate
because
that's
that's
has
kind
of
specific
connotations
like
that
means.
Usually
that
means
like
this
is
a
release
you
can
try
out
and
if
it
works
out,
we're
gonna
release
this,
whereas
if
it
was
just
pointing
out
like
a
development
branch
or
something
that
would
be
more
of
the
upcoming
release,
where
it's
it's
like
all
the
changes,
it's
not
like
necessarily
a
snapshot
that
we
think
we're
gonna
release.
It's
a
it's
just
like
the
latest
version,
but
we
can
just
maybe
name
incan
yeah.
C
C
You
know
it's
a
it's
a
it's
a
production
candidate,
but
this
is
like
the
difference
between
what
a
release
really
is
versus,
like
a
version
that's
available
for
people
to
build
off
of
all
these
words,
but
you're
you're,
totally
right,
okay.
So
a
couple
of
recaps
I'll
find
that
issue
Nathan
because
I
know
I
created
it.
I've
created
it
after
talking
with
Marin
over
and
delivery.
So
when
I
talked
with
him,
they
used.
You
know
they
cut
our
branch
on
the
18th
and
that's
our
release
candidate
that
we
then
promote
right.
B
C
C
The
initial
MVC
might
be
to
elevate
one
to
create
like
a
our
tech
evaluation
for
this,
but
then
to
elevate
all
of
the
project
functionality
of
releases
up
to
the
group
and
add
it
to
a
side
panel
option
and
associate
multiple
tags
per
group
release
one
one
per
project:
okay
and
then
in
the
future.
We
may
decide
to
break
tags
from
releases
to
support
this
idea
about
coming
releases.
But
that
might
be
that's
a
very
future
thing.
John
writes.
D
My
thought
is
that
we'll
have
to
break
it:
a
technical
level
like
global
yeah.
Technically
we
will,
but
from
the
users
point
of
view,
you
can't
you
still
can't
create
a
release
without
any
tags
associated
like
at
an
application
level.
Well,
so
we'll
enforce
that
you
have
either
one
for
project
or
at
a
group
one
one
or
more.
Okay,.
B
A
A
A
C
That's
not
like
an
artificial
extra
step
right
so
I
as
a
user
I
would
need
to
create
my
project
release
first
and
when
this
is
automated
with
the
amyl
file,
it
might
be
negligible,
but
today
I
would
need
to
create
my
project
release
and
then
I
would
need
to
associate
that
release
to
a
group.
That
extra
step
seems
completely
unnecessary
when
they
could
just
associate
it
with
a
group
release
that
tagged
with
a
group
release
mm-hmm.
A
B
C
B
Yeah
they
did
they're
different.
The
two
I
think
we've
come
to
the
conclusion
of
the
to
the
group
level
release
and
the
project
live.
Release
are
different
and
maybe
we
do
call
it
version.
Although
I
think
releases
is
fine,
but
then
add
that,
but
though
at
the
group
level
you
got
to
release
and
then
at
the
project
level,
you've
still
got
you've
got
the
existing
release
and
at
the
project
level
each
release
must
equal
one
tag
and
in
at
the
group
level,
there's
multiple
tags
or
releases
associated
with
the
with
the
group
level
release.
D
B
C
Right
so
I
think
maybe
MVC
Ayana.
We
can
support
this
idea
of
you
have
your
project
releases
and
you
must
associate
them
to
a
group
release
in
order
to
take
advantage
of
the
group
release
functionality,
but
I
think
we'll
will
soon
discover
that
that's
just
a
duplicate
of
step
that
will
reduce
adoption
of
group
releases,
especially
if
the
goal
is
to
orchestrate
and
plan
releases
across
multiple
things.
So
two
two
questions:
should
I
schedule
a
follow-up
for
this
or
do
we
feel
like
we
can
do
this
asynchronous?
D
C
Perfect
so
I'll
publish
these
notes
in
the
epic,
because
I
was
just
taking
notes
in
a
comment
and
then
create
a
couple
of
sub
issues
and
then
open
up
a
tech
evaluation
for
this
Shawn,
and
we
can
start
work
on
that
in
the
next
milestone
yeah
to
either
discover
what
it's
gonna
take
to
fracture
the
tag
from
the
release
on
the
back
end,
even
though
the
front
end
won't
we're
not
I
said
the
front
end,
but
the
user
won't
experience
that
we
can
go
from
there.
Yeah.
B
Any
type
because
I
think
we
have
to
do
that
then
be
in
basically
I,
don't
know.
Maybe
we
don't
want
to
bite
this
off,
but
it
could
include
the
scenario
where
you
don't
have
a
release
at
the
project
level.
I
need
a
strictly
associated
tag
with
the
group
level.
Release
I
mean
I,
don't
think
it'll
be
a
big
issue.
I
think
fracturing
the
the
two
is
actually
gonna
be
was
gonna,
be
you
know
it's
going
to
be
tricky,
but
you
know,
of
course
it
probably
should
have
been
done
in
the
first
place.
B
You
know
when
it
was
originally
built,
but
once
we
were
slit
and
then
I
think
to
associate
and
I
don't
know
depends
what
we
want
to
do
in
the
embassy,
but
I
I
think
that
it
might
be
actually
more
work
to
to
support
to
not
support
it
straight
away.
Basically,
I
think
it
would
be
simpler
if
we're
already
breaking
everything
apart
to
just
you
know,
let's
just
go
all
the
way
and
have
the
group
level
release.