►
From YouTube: 2022-11-16 Delivery:Orchestration demo - EMEA/AMER
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Okay,
where
coming
from,
let's
give
me
a
second
I'm,
just
waiting
for
YouTube
page
to
update
so
welcome
everyone.
This
is
16th
November.
The
orchestration
demo
I
will
kick
off
with
the
first
action,
because
this
is
quite
a
fun
one,
after
digging
through
a
bunch
of
Zoom
settings.
So
for
those
of
you
were
here
last
week,
I
had
an
action
to
figure
out
why
we
couldn't
live
stream.
Last
week,
I
actually
concluded
that
I
think
it
was
because
we
had
those
Zoom
problems.
A
I
think
that
was
why
the
feature
wasn't
available.
I
didn't
change
anything
so
I
think
it's
okay,
but
I'll
double
check
for
you
Matt
on
whether
that's
the
the
course
for
your
stuff.
So
this
may
be
working.
Let
me
go
and
double
check,
but
over
to
the
demo
section
so
very
happy
to
see.
We
have
a
couple
of
items
here
so
go
get
my
art
Steve
for
for
getting
things
ready
to
be
demoble
Myra
I'll
hand
over
to
you,
yep.
B
C
You
so
I'm
gonna
share.
My
screen,
probably
gonna
assure
my
whole
desktop
okay
I,
assuming
you
are
seeing
my
screen
and,
if
not,
please
say
something
so
I
want
to
demo.
How
are
we
going
to
fetch
or
how
are
we
going
to
yeah,
basically
get
the
number
or
on
release
commits
for
active
style
right,
the
stable
branches,
and
for
that
just
a
bit
of
context?
C
So
right
now
we
have
the
release
manager
dashboard
and
to
see
the
release
pressure.
While
we
observe
this
graph-
and
this
graph
basically
tell
us,
okay,
we
have
four
merch
requests
with
a
peak
into
label
for
15.5,
then
we
have
12
and
then
we
have
16..
C
I
can
actually
click
this
and
corroborate.
So
for
15.5
we
have
four
merge
requests
with
this
label
and
then,
if
I
click
on
this,
we
have
well
four
merch
requests
with
Peak
into
15.4,
and
we
can
see
that
we
have
a
lot
and
well.
The
same
is
going
to
go
for
15.3.
B
C
For
example,
if
we
go
to
the
stable
branch
of
gitlaf,
like
the
current
stable
branch,
which
is
15.5,
we
can
see
that
we
actually
don't
have
any
unreleased
commit
because
all
of
them
were
merged
after
the
last
attack.
So
this
is
the
last
start
like
15.5.4
and
well.
We
can
corroborate
that
if
we
take
a
look
at
the
dash,
so
the
last
attack
15.5
that
far
and
well
the
commit
is
basically
the
same.
We
have
d3dd
and
then
it's
well.
C
It
is
the
same
another
easy
way
to
take
a
look
at
this
is
and,
of
course,
if
the
zoom
control
lets
me
move
ahead,
come
on
move.
Okay,
yes,
is
to
see
the
compare.
So
in
the
compare.
This
is
a
very
handy
page
that
we
can
compare.
Okay,
what
is
the
difference
between
the
stable
branch
and
the
dash,
and
we
can
see
that?
Okay,
we
don't
have
anything
so
415.5
everything
has
been
released.
C
It
is
not
the
same
story
for
Italy,
for
example,
in
Italy.
We
can
see
that
we
can
do
the
same
comparison
and
we
can
see
okay
I'm
going
to
compare
the
commits
between
the
stable
branch
and
the
last
task
and
I
can
see
that
we
actually
have
two
commits
that
have
been
merged
into
a
stable
Branch,
but
have
not
been
released.
So
there
is
still
a
pressure
in
this
in
this
project
for
Italy.
C
Now.
What
we
have
been
doing
for
this
is
to
basically
add
some
classes.
These
merge
request
is
still
in
progress.
Well,
it
is
still
in
reviewed.
It
has
been
reviewed
by
Steve
and
alexio
and
I'm
hoping
to
get
it
merge
soon,
but
basically,
what
I'm
going
to
demo
today
is
going
to
be
these
classes
and
just
to
make
it
very
brief.
C
This
class
is
going
to
fetch
what
are
the
current
versions
we
have
according
to
the
maintenance
policy
or
to
the
new
maintenance
policy,
and
then
for
each
of
those
versions,
is
going
to
iterate
for
the
projects
that
are
on
their
managed
versioning,
which
is
git,
love,
Omnibus,
Italy
and
CNG,
and
then
it
is
going
to
get
basically
the
unreleased
commit
for
stable
Ranch
now
I
know.
This
sounds
very
blurry,
but
it
is
going
to
be
very
I
think
more
obvious,
once
I
demo,
this
so
I,
assuming
that
now
you
can
see
my
terminal
right.
C
And
then
well,
the
first
thing
is
that
you
can
notice
is
that
it
is
going
to
fetch
all
the
versions
that
are
current
under
the
new
maintenance
policy,
which
is
going
to
be
like
right
now.
It
will
be
15.5,
then
15.4
and
then
15.3
and
then,
if
I
type,
execute
the
method
well,
it
is
going
to
start
making
some
requests
now.
This
is
very,
very
verbose,
but
it
is
actually
easy
to
explain
so,
of
course,
Zoom
doesn't.
Let
me
see
anything
so
I'm
going
to
move
this
around
all
right
awesome.
C
So,
for
example,
for
the
first
one
we
can
see
that
okay,
it's
analyzing
git
love
the
project.
It
is
analyzing
15.5.4
and
it
is
comparison
comparing
that
against
the
branch-
and
it
is
saying:
okay,
we
don't
really
have
any
commits,
which
is
just
that.
If
that
the
compare
page
that
we
saw
on
the
on
the
web-
and
it
is
saying
the
same
for
Omnibus
and
for
example-
then
it
is
going
to
analyze
Italy
and
on
Italy,
saying
hey,
we
do
have
some
stuff.
We
do
have
actually
two
commits.
C
It
is
going
to
analyze
gitlab
only
boost
Italy
and
CNG,
and
then
it
is
going
to
start
with
15.3
and
then
again.
Git
love,
Omnibus,
Italy
and
CNG
is
right
here,
but
the
end
result
is
the
well
the
thing
that
it
is
the
most
important
here
it
is
going
to
return.
Okay
of
those
four
projects
like
what
is
the
total
of
unreleased
commits
and
for
those
projects,
is
basically
three
for
15.5,
then
for
15.4
is
1
and
for
15.3
is
5..
C
Now
this
is
the
information
that
we
want
to
send
to
delivery
metrics,
so
it
gets
pushed
and
then
well
visualize
in
the
release
manager
dashboard
by
doing
this
I
notice.
Well,
this
is
the
demo,
but
by
doing
this,
I
noticed
that
the
on
release
commit
information
is
useful,
but
it
is
not
the
most
accurate
because,
for
example,.
D
Destroy
comparing
sorry,
can
you
try
comparing
with
so
CNG.
This
is
something
that
I
noticed
when
I
was
reviewing
your
merger,
not
the
merge
request,
but
a
documentation
update
so
CNG.
It's
a
strange
Beast.
It's
talking
four
times
for
each
version.
So
is
it
possible
asking
here
that
the
last
so
if
we
first
do
CE
and
then
we
do
EE
and
that's
the
reason
why?
Because
we
have
a
stable,
a
single,
stable
Branch,
but
multiple
tags
so
is.
C
C
I
thought
about
it,
but
I
think
the
tax
is
the
same.
The
content
of
the
tax
is
the
same.
So
this
one
and
let's
see
so
I
lied.
So
it
is
not
it
is.
There
is
no
diff
okay,
so
that
works
but
I
guess
the
problem
is
going
to
happen
for
any
other
projects,
for
example,
for.
D
C
Yeah,
exactly
I
guess:
well,
no,
actually
I
think
in
this
case
there
are
two
merge
requests.
So
the
actual.
C
Oh
yeah
you're
right
you're
right,
so
my
question
would
be
the
same.
The
number
of
unreleased
committees
in
for
is
Handy,
but
it
is
not
completely
accurate
and
I
guess
to
move
to
actually
measure
the
pressure
for
patch
releases.
We
will
need
to
use
merge
requests
not
commits.
We
can
use
merch
kind
of
avoid
yeah
yeah
to
kind
of
avoid
the
situation
and
the
one
from
CNG.
B
A
Yeah
I
can
hear
me
now:
yeah,
yes,
okay,
great,
do
you
mean
my,
or
do
you
mean
about
that
last
point
or
about
General
where,
when
you
say
like
what
do
you
think
what
what's
the
framing
of
that
question.
C
Yeah,
thank
you
about
using
merch
commits
or
merch
requests
as
a
more
accurate
metric
for
patch
pressure.
C
So
we
could
use
on
release
commits,
as
is,
but
that
would
not
be
very
accurate
because
all
of
these
scenarios
we
could
use
smartra
class,
which
I
think
is
going
to
make
the
match
a
bit
more
accurate,
or
we
can
also
make
it
smarter
and
use
a
combinations
of
merch
requests
with
priority,
because
we
could
have
a
lot
of
merge
requests
merge
into
a
stable
Branch,
but
all
of
those
nurture
quests
could
be
like
documentation,
changes
or
could
be
like
bug
fixes
for
flacky
failures.
D
I
was
saying
that
what
we
have
here
is
just
the
list.
What
we
can
download
with
the
code
that
Myra
showed
up
is
a
list
of
of
commits,
but
then
we
can
see
from
the
commits
itself
if
it's
a
merge
commit
or
not.
So
in
in
case
like
this.
So
let's
say
that
we
have
old
patches
with
just
one
single
commit.
We
are
going
to
see
the
the
pressure
would
be
double
the
real
pressure,
because
every
commits
will
commit
code
change,
commit
plus
the
merge
commit
right.
D
So
when
either
we
know
that
the
number
is
at
least
double
it
could
be
double
or
otherwise.
D
It
can
be
even
worse
because
if
someone
made
patch
made
of
several
commits,
but
it's
a
single
merge
request,
then
it
will
count
more
for
for
no
reason
so
to
keep
it
see
in
parity
with
what
we
have
right
now,
let's
see
if
we
can
filter
just
by
merge,
commit
it's
going
to
give
the
same
value
to
build
on
top
of
what
Myra
was
proposing
and
and
kind
of
something
that
came
to
my
mind
when
I
was
now
seeing
the
code
in
action
is
that
we
are
kind
of
losing
information
when
we
extract,
because
we
get
out
a
number.
D
So
we
see
this
is
the
version.
This
is
the
number.
Each
version
has
a
unreleased
commit
number,
but
now
that
we're
going
to
push
this
to
a
matrix,
we
could
say
something
like
say:
counting,
merge,
requests
right,
commit
I,
think
we
all
agree
that
counting
the
single
commits
is
kind
of
not
really
worth
doing,
but
if
we
could
add
what's
the
label,
because
this
is
a
metric
labels
counting
for
the
project
and
the
priority,
then
we're
gonna
have
something
like
a
matrix
that
can
sum
everything.
D
So
we
say:
what's
the
overall
pressure,
because
it's
symmetric,
so
you
can
sum
everything
on
this
metric
and
just
give
a
number.
But
then
you
can
see
tell
me
the
number
of
P1
changes
or
tell
me
the
number
of
gitly
changes.
So
we
can
do
breakdown
on
on
several
Dimension
project
and
priorities
and
being
this
labels
is
something
that
we
can
consider
adding
later.
If
we
don't
want
to
go
at
the
beginning
with
a
full
implementation.
D
I
would
say,
probably
split
by
project
is
something
we
should
bake
in
since
the
beginning,
because
it's
easy,
we
already
have
I
mean
it's
the
easiest
things
to
get
out
because
we
fetch
by
project,
but
then
we
have
something
so
we
can
just
have
nested
keys
so
that
we
can
push
the
value
by
by
project.
This
is
simple:
there's
no
extra
things
involved
like
trying
to
figure
out
what
what
is
the
merge
request
and
the
priority
of
the
merge
requests
and
things
like
that
yeah.
So
that's
that's
was
the
basic
idea.
C
Yeah
yeah,
so
to
summarize
I
think
we
should
definitely
use
merge
requests
and
then
we
can
extend
the
information
that
is
returned
to
also
return
unreleased
commits
by
project
Group
by
version,
which
is
going
to
be
more
informative
than
just
the
plain
number
so
yeah.
C
C
D
What
happened
for
the
change
log?
Because
that's
the
thing
right,
so
the
changelog
comes
from
the
comet,
so
they
may
have
done
something.
This
is.
This
is
what
we
support
in
development
workflow
right,
so
they
can
build
something
which
is
made
of
several
commits
and
each
one
has
a
changelog
entry
and
when
you
say
backboard,
they
say:
okay,
I'm,
gonna,
backport
the
whole
thing,
so
it's
gonna
bring
all
the
commits
with
their
own
history
and
change
lock.
D
D
But
yeah
I
think
it's
it's
not
important
to
us.
I
mean
it's
just
okay.
If
we
can
filter
by
identifically,
identify
the
merge,
commit
and
I'm
sure
we
can,
then
it
we
don't
really
bother
about
how
many
things
are
in
there
right,
because
it's
it's
a
stable
Branch,
it's
going
to
be
merged,
it's
going
to
be
have
its
own
QA
and
test
run,
and
if
it's
one
commit
ten
commit
thousands
I
mean
I
will
leave
this
to
the
release,
not
released
the
maintainer
description
say
so
we
are
changing.
C
Well,
I'm
Gonna
Save
my
comments
there
I
I
would
like
to
to
ensure
some
cleaning
less
cleanliness
in
the
stable
Branch,
but
I
guess
that
is
a
completely
different
story,
but
in
regards
with
the
work
that
grams
is
doing,
I
remember
that
he
wants.
He
wants
to
spin
up
an
environment
every
time
something
is
pushed
to
the
stable
Branch.
So
perhaps
he's
going
to
require
to
apply
the
same
logic
it
needs
to
to
create
an
environment
per
merch
commit
instead
of
every
commit
I'm,
not
sure
if
that
is
going
to
affect
that.
D
But
now
it
should
not
affect
that
because
it,
the
real,
commit
Landing
on
stable
branch
is
the
merge
commit
because
before
you
merge,
they
are
on
on
another
branch
and
when
you
merge,
the
head
of
the
branch
is
the
merge
commit.
So
the
question
for
him
is
more
about
what
happens
when
you
have
several
competing,
not.
D
Several
merge
requests
merged
at
the
same
time.
Which
is
less
common
and
in
this
case,
but
could
still
happen,
and
we
were
discussing
the
there's
a
feature
in
the
CI
that
I
don't
remember
right
now
when
you
say
that
a
job
may
be
obsoleted
by
the
next
one,
and
so.
A
Myra,
how
how
would
a
new
project
component
or
something
get
registered
into
this
like
if,
when
we,
when
we
do
the
work
to
start
patching,
something
else
like
do,
we
also
have
other
documentation
or
things
that
we
need
to
make
sure
we
know
to
make
changes
here
or
is
there
some
automated
thing
involved.
C
Yes,
good
question.
Thank
you.
So
in
release
tools,
we
actually
have
a
lot
of
places
in
which
these
projects
are
listed.
I
think
Alicia
brought
this
once
and
we
have
a
lot
of
technical
depth
there.
So
for
these
merch
requests
for
this
merch
request,
what
I
did
is
to
try
to
centralize
this
logic
into
a
single
file.
So,
for
example,
this
file
under
our
code
base
is
listing.
C
Okay,
all
these
projects
are
right
now,
the
ones
that
are
under
managed
versioning,
so
if,
by
tomorrow
or
like
in
a
month,
we
want
to
add
car.
So
we
want
to
add
pages.
We
will
need
to
we'll
make
sure
that
they
comply
with
all
the
requirements
for
manage
versioning
and
then
add
this
the
project
here
in
this
list,
so
it
will
be
automatically
included
into
all
these
computation
and
yes,
I
I
am
going
to
document
that.
C
Sure,
well,
we
do
more,
but
these
are
the
only
ones
that
we
include.
They
pick
into
label.
A
E
E
So
yeah,
so
mine
mine
actually
had
branches
off
the
Myers
Branch
because
we
realized
that
we're
both
kind
of
fetching
a
lot
of
the
same
information
and
and
so
with
the
release
post
or
with
a
blog
post
for
the
patch
release.
Currently
it
is
it's
it's
generated
automatically
when
the
prepare
command
is
run
in
chat,
Ops,
I,
believe
and
then
anytime
during
the
actual
patch
process.
When
people
are
running
the
merge
command
and
chat
Ops,
we
bring
in
the
different
Mr
descriptions
and
those
get
inserted
into
the
blog
post.
E
So
now,
since
we
won't
be
doing
that
process
in
the
same
way,
we
want
to
be
able
to
just
create
the
blog
post
once
like
at
the
time
of
tagging
or
at
you
know
any
particular
time
just
based
off
of
sort
of
that
same
idea.
Where
there's
this
release
pressure
and
anything
that's
on
that
list
should
be
included
in
the
blog
post.
E
So
first
I'll
start
out
by
kind
of
demoing
this
break
task
and
showing
what
it
kind
of
does
and
so
I
chose
to
just
start
a
new
rake
task,
and
that
way
it's
sort
of
isolated.
It's
not
run
by
anything
else,
but
the
idea
being
that,
if
you
run
this
task,
then
it
will
generate
the
blog
post
and
and
it'll
create
the
merge
requests
for
you.
E
So
it's
just
this
release
patch
release,
blog
post
task
and
I'm
doing
a
dry
run,
yep
occurred
and
so
you'll
see
a
lot
of
similar
things
from
what
Myra's
was
doing,
because
at
first
it
also
collects
all
of
the
commits.
But
then
we
do
take
it
a
step
further
and
then
collect
the
merge
requests
from
those
commits.
E
So
here
we
can
say-
or
we
can
see,
that
from
the
gitlab
project-
we're
collecting
the
commits
for
this
version,
and
we
can
see
that
there
were
no
commits,
unfortunately,
so,
but
then
right
after
that,
it
would
have
fetched
merge
requests
for
those
commits,
but
in
this
case
it
did
not
and
actually
did
it
did
it
actually
fetch
any
merge,
requests.
I'm,
not
sure
it
looks
like
it
did
not
so
that
yep
I
think
down
here.
We've
got
a
couple,
but
one
other
thing:
I'll
do
real.
E
Quick
is
we
can
actually
look
at
what
the
output
of
this
by
if
we
look
at
the
rate
task,
so
the
rate
task
is
using
that
same
coordinator,
to
generate
this
content
and
we
create
the
blog
request
or
blog
merge
request
by
using
by
providing
it
a
set
of
versions
and
then
a
set
of
blog
content
from
this
coordinator
and
then
what
I
will
do
is
I
will
remove
this
single
dry
run
so
I'll
end
up
writing
a
file
to
my
system
of
what
the
blog
post
will
look
like,
and
we
can
run
this
one
more
time.
E
There's
one
commit
right
here,
so
if
we
come
back
in
here,
you
can
see
here.
I
created
a
markdown
file,
and
inside
of
here
there
was
only
one
version
that
had
a
single
merge
request,
which
was
that
giddly
one
that
we
saw
so
it
is
listed
here
and
so
the
way
I've
set
it
up
is
even
though
it's
representing
these
three
versions,
it
will
only
actually
add
a
section
currently
if
there
is
something
to
list.
E
And
interestingly
one
of
the
things
that
we
kind
of
just
discussed
about
the
merge
commits
versus
the
code
commits
I.
Think
I
noticed
when
there
is
a
or
the
way
I've
set
it
up.
Is
we
take
all
of
the
commits
that
that
come
in?
So
this
is
that
unreleased
commits
that
Myra
had
implemented,
and
then
we
find
all
the
different
merge
requests
for
each
commit,
and
so
I
did
I
do
duplicate
them
so
that
we
only
have
a
listing
of
one
merge
request
for
each.
E
You
know
if
there's
multiple
commits,
but
then
there
are
a
lot
of
cases
where
we
have
commits
that
are
not
associated
with
any
merge
requests.
So
this
kind
of
removes
them
as
well,
because
there
won't
be
any
merge
requests.
So
that's
why,
even
though
there
might
have
been
a
couple
commits,
we
only
ended
up
with
one
listing
here
and
when
I
ran
it
the
other
day.
E
I
ran
one
on
previous
versions,
and
so
you
can
see
here,
I
think
one
of
these
merge
requests
that
popped
up
here
actually
had
eight
or
nine
commits,
but
it
all
got
kind
of
squashed
down
into
one
and
let's
see,
if
there's
anything
else,
really
interesting
going
on
in
the
code
but
yeah.
The
main
idea
is
pretty
much
in
this
coordinator,
which
we
saw
a
little
bit
from
Myra
oops.
That's
the
wrong
coordinator
foreign.
E
So
we
we
use
the
same
set
of
versions
and
then,
in
this
case,
for
the
blog
content,
we
grab
the
unreleased
merge
requests
for
any
given
project
version,
so
we're
kind
of
doing
the
same
thing
here
to
an
extent
we
go
through
each
version
and
each
project
grab
all
of
the
merge
requests
and
then
just
put
them
in
a
collection
of
version
and
merge
requests
so
that
they
can
be
listed
out
in
the
blog
post,
with
one
section
per
version,
at
least
for
now
and
yeah
I.
E
Don't
think,
there's
anything
else
that
I
kind
of
missed
here,
but
the
actors
on
any
questions
or
anything
in
particular
that
you
see.
A
I
have
a
question
which
is
sort
of
you've,
maybe
realized
it's
not
directly
linked
to
the
blog
post,
I
guess,
but
in
the
event
that
we
we
did.
That
was
the
patch
release
that
we
were
publishing
and
it
was
just
on
the
one
version.
A
E
That's
a
question
I'm,
not
sure
if
I
know
how
to
answer
I
mean
I
know
this
like
in
terms
of
the
blog
post.
This
will
just
be
an
MR,
so
it
can
easily
be
edited.
But
in
terms
of
how
the
package.
E
A
Because
I
mean
like
we
could
certainly
I
guess
what
what
I
was
leading
up
to
asking
was
that
if
that
was
the
case,
then
what
we
can
do
is
just
add
some
guidelines
for
release
managers
that
we
could
do
like
a
little
cleanup
on
this
blog
post
to
just
make
it
specific
to
the
the
versions
but
Myra
have
you
given
some
thought
already
onto
like
what
would
you
want
to
happen.
C
Yeah
I
think
it
is
one
of
those
open
questions
that
we
have
right
now.
For
me,
it
will
be
natural
to
only
if
we
only
have
one
merch
request
for
one
version,
then
it
will
be
just
two
well
to
ship
that
version
and
not
to
ship
three
empty
packages.
C
But
then
again
it
will
be
some
sort
of
weird
case,
because
if
we
only
have
one
commit,
that
means
that
we
shouldn't
have
started
a
pass
release
in
the
first
place,
because
there
is
not
enough
pressure.
No.
A
Necessarily
right,
we
could
have
like
an
S1
there's
only
on
one
version
like
I
I
guess
like
it's,
not
a
big
deal,
but
I
just
I'm,
just
curious,
I
guess
as
to
like
what
we
are
intending
to
see
because
I
think
that
will
allow
us
like.
If
we
are
saying
theoretically,
we
could
put
out
one
version
like
a
package.
A
D
I
have
a
follow-up
question
or
I
mean:
let's
see
it's
follow-up
question,
it's
cylinders!
It's
if
we
change
the
when,
if,
when
we
change
the
policy,
will
the
policies
state
that
we
must
support
three
versions,
which
means?
A
D
A
Think
generally,
we
would
want
to
fix
in
all
three
and
I
would
be
surprised
if
there
was
a
product
manager
who
said
I
don't
want
to,
but
I
also
doubt
it
would
be
a
set
in
stone
like
I
could
imagine
a
scenario
where
you
have
a
bug
fix
in
say
the
last
two
versions
and
actually
trying
to
fix
it
in
the
the
third
version
might
actually
cause
another
problem
based
on
code
right
like
I
I
could
imagine
some
scenarios
where
it
might
actually
be
worse
to
put
the
bug
fix
in
and
that
we
may
make
a
decision
not
to
I
think
it
probably
depends
on
the
bug.
D
Yeah,
but
so
you
will
say
that
the
Baseline
is
that
if
the
patch
cleanly
applies,
you
will
apply
on
all
the
three
version
right,
because
this
is
what
we
say
we
support
it.
So
I
think
this
will
truly
diminish
the
possibility
of
not
having
something
to
release
I
mean
if
you
just.
If
you
look
at
the
the
pressure
right
now,
I
think
I've
never
seen
things
being
a
zero,
but.
C
D
Yeah
we
may
strive
to
have
this
process
so
simple
that
we
may
consider
running
as
much
as
we
can,
and
so
we
may
end
up
in
a
situation
where
actually
we
we
are
working
off
that
cure
right.
So
we
we
see
the
pressure
high
now
because
we
never
do
we
never
patch
the
older
one.
But
maybe
that's
true
that
maybe
you
do
once
and
then
the
older
version
to
to
end
up
not
having
stuff
so
yeah.
A
A
Is
nothing
there
yeah
and
what
I'm
thinking
about
is
it's
I
guess
what
the
risk
I
was
seeing
of.
The
mismatch
is:
if,
if
we
don't
publish
a
package,
then
if
we
say
in
the
blog
post
that
actually
also
included
a
15.3.5,
but
we
actually
didn't
publish
a
15.3.5,
then
the
next
time
the
version
numbers
will
be
out
of
sync.
A
D
D
Relevant
to
at
the
end,
we
publish
and
we
Mark
what
we
have
released,
because
this
triggers
notification
to
upgrade,
and
things
like
like
that
in
the
instances.
So
there
are
things
related
to
that,
so
no
everybody
will
still
be
off
right
because
you'll
see
I
mean
it's
on
the
screen
right
now.
Today
we
are
releasing
versions,
one
two
three
and
then
see
this
version
does
not
exist,
but.
E
D
E
But
I
think
it'll
be
interesting
from
the
product
manager
perspective
to
see
how
things
happen,
as
this
initially
is
released
because
I
I
think
like
what
I've
seen
is
that
bugs
either
just
go
into
the
current
version
and
there's
no
question
about
backwards
or
or
it's
backboarded
and
and
so
I
would
expect
that
it's
yeah
it's
either
even
just
B,
it's
not
back
ported
at
all,
or
hopefully
it's
done
in
all
three
but
it'll
be
interesting
to
see
whether
or
not
the
product
managers
actually
follow
that
behavior
right
away.
A
Oh,
yes,
definitely
definitely
great
thanks
for
downloading
Steve.
Is
there
anything
else
you
want
to
discuss
or
get
from
that
around
that
demo
before
we
move
on.
B
I,
don't
think
so.
What's.