►
Description
Meeting agenda: https://docs.google.com/document/d/1aPgGRl4WewM3txrCYvkepsxLUvGdMG1EzlVfCNeV74M/edit#bookmark=id.99ap6clo8ul8
A
A
So
there's
one
item
that
I
put
on
the
agenda
that
I
just
wanted
to
talk
about,
and
this
came
up
on
the
review
for
the
pr
that
I
put
up,
basically,
which
which
release
Branch
naming
do
we
want
to
use
Joseph
I
saw
your
comment
there
and
I.
Think
I
tend
to
agree
with
you
like
I
would
probably
keep
the
release,
naming
the
same
as
whatever
the
project
is,
but
I,
just
I
drafted
off
of
what
client
go
did
so
I
just
kind
of
copied
what
their
guidance
is?
B
I
guess
I
can
take
a
turn
and
then
I
know.
Iran
also
just
gave
a
review
like
just
a
few
minutes
before
the
meeting,
so
I'm
curious
his
thoughts.
Besides
what
I
said,
I
sort
of
thought
about
it
later
and
I
wondered
if
client
go
might
have
tighter
release
automation,
that's
a
little
more
coupled
with
the
rest
of
kubernetes.
B
So
if
that's
in
the
cards
for
the
future
for
connectivity
proxy,
then
that
could
be
a
reason
to
go
that
way.
But
while
it's
manual
I
sort
of
like
the
consistency
of
matching
the
release
tags,
also
I
thought
about
it.
It's
always
going
to
be
easier
to
go
forward
and
like
harder
to
go
backward
harder
or
impossible
to
go
backward.
So
it's
a
little
bit
more
conservative
approach
to
stick
with
release
Dash
zero
for
now
Imran.
What
do
you.
C
Think
so,
I
don't
have
a
preference
of
adding
that
release
prefix,
but
I
had
a
question
whether
it
should
match
the
kubernetes
version,
the
name
of
the
branch
or
it
should
match
the
the
tag
of
the
on
the
API
server
epoxy
side,
so
release
1.99
or
release
0.99.
So
that
was
my
question,
but
I'm
having
a
really
specifics
is
is
okay
for
me,
I
I
I
would
be
on
that
side
of
having.
A
Okay,
so
it
sounds
like
we're
all
in
agreement
about
using
the
zero
dot,
using
the
same
name
as
the
release
as
the
tag
we
use
like
I'm
good
with
that
too
I
don't
know
and
welcome.
David
I
just
saw
you
come
in
we're
talking
about
the
release,
Branch
naming
for
how
we're
going
to
work
the
project-
and
we
were
kind
of
discussing
you
know
we
were
drafting
off
kind
of
client-
goes
tagging
and
branching
scheme.
A
But
one
thing
that
one
thing
the
client
go
does
is
they
keep
the
minor
version
of
the
kubernetes
and
they
use
zero
as
the
major
version
for
their
library,
but
when
they
Branch
they
use
like
release
Dash
and
then
the
major
number
from
the
kubernetes.
So
we
were
kind
of
going
back
and
forth.
Do
we
want
to
do
really?
Do
we
want
to
do
a
client
go
style
where
we'd
say,
release
Dash?
A
You
know
1.99,
for
example,
if
1.99
was
the
latest
kubernetes
release
or
do
we
want
to
stick
with
our
tag,
which
would
be
0.99
and
just
call
it
release
Dash
0.99
and
welcome
Walter,
just
so
you're
coming
through
we're
kind
of
going
back
and
forth
about
what
just
resolving
this
last
issue.
With
the
release
naming
here.
D
A
A
E
A
A
A
B
I
can
go
first,
so
I
confess
I
still
haven't
done.
The
work
I
promised
a
while
back
to
update
to
the
latest
kept
template,
but
I
will
say,
though,
that
we
have
a
contributor,
I
guess
tall
Claire
who's,
the
teammate
of
Walters
in
mine
and
he's
back
from
leave
and
he
sent
he
opened
a
fairly
ambitious
PR
that
does
a
big
test
refactor
with
basically
implementation
progress
towards
the
version.
E
D
E
D
E
D
E
Well,
and
just
to
be
clear,
I
mean
when,
when
I
was
putting
a
lot
of
this
together,
I
was
working
closely
with
David
and
the
agreement
we
had
was
to
not
to
build
a
final
level
grind
of
control
while
we
were
proving
it
out,
but
to
do
it
with
the
existing
controls
and
so
I'm,
not
necessarily
against
finer
grain
controlled.
But
I
think
that
is
a
level
that
that
is
a
much
deeper
change
in
the
API
Machinery
code
than
what
we
originally
made.
E
E
To
being
you
know,
cloud
provider
extracted
as
the
default
and
I
mean
when
that's
all
trying
to
go.
Do
the
network,
the
cloud
provider,
extraction
effort
and
in
fact
this
was
the
first
success
in
cloud
provider
extraction
it.
This
is
the
piece
that
allowed
us
to
remove
SSH
tunnels,
so
I
I,
just
you
know
a
little
bit
of
a
pat
on
the
back
to
everyone
here.
E
A
A
I
think
there
are
still
a
couple
Corner
cases
that
we're
still
trying
to
work
out,
but
yeah,
like
I'm
I'm
gonna,
get
back
into
updating
the
cap
to
get
us
to
the
next
Point,
because
I
think
we're
we're
rapidly
approaching
the
beta
stage.
So
I
I
share
your
optimism.
Walter
I
think
in
the
next
couple
releases
yeah
we'll
be
able
to
get
everything
out
of
there.
So
that's
very
cool
and
and
kudos
to
all
of
y'all
for
who've
been
in
this.
For
you
know
many
more
years
than
I
have.
E
Yeah
Tim
Tim
Hawkins,
told
me
to
make
this
happen
about
four
years
ago
and
I
told
them
it
would
take
four
or
five
years
and
he
said
we
can't
take
that
long.
Come
on
be
serious.
I'm
like
no
it's
it's
gonna.
Take
that
long,
I
think
I
disappointed
Tim.
When
I
told
him
it
was
going
to
take
this
long,
but.
B
I
have
a
tactical
agenda:
it's
okay!
If
people
want
to
drop
I
just
wanted
to
talk
about
recent
tags,
so
I
think
Imran
has
a
PR
and
KK
to
put
0.1.4
there
in
in
master
branch.
Is
that
right?
I
saw
some
movement,
but
I
know
that
those
move
kind
of
slowly
and
then
immediately
following
that
that
Nilda
ref
Panic
PR,
that
I
authored
that
is
merged
fairly
recently
still
needs
a
tag
so
I
think
I.
B
Will
you
know
once
I
I
was
I
will
use
the
El
Miko
release
and
tagging
strategy,
so
I
see
what
I
need
to
do,
but
I
I
think
it's
worth
backporting
that
in
Elder
ref
fix
to
the
supported
range
in
KK.
According
to
the
you
know,
tag
scheme
that
we've
got
laid
out
so
I
intend
to
do.
I
intend
to
do
that
in
the
near
term.
E
E
B
A
B
E
E
We
could,
but
that
means
that,
like
on
the
xero
from
what
we
call
the
zero
one
line,
if
you
wanted
to
have
both
the
26
and
the
27
image,
we
would
need
to
cut
two
images
or
at
least
tag
the
image
twice.
Okay,
that's
what
we're
saying
to
that
I'm
fine
with
that,
but
that's
exactly
the
question
I'm
asking
no.
B
A
Yeah
like
if
we
cut
a
new
image
and
we're
taking
it
back
into
the
old
days,
then
I
mean
I.
Don't
like
my
personal
feeling
is
like
from
here
forward.
We
should
probably
start
using
the
new
naming
sequence
for
everything,
because
it's
clearer
but
I
think
I'll
need
to
adjust
the
readme,
then
just
to
say
like
look,
we
have
these
historical
versions
and
here's
how
you
interpret
them
going
forward.
E
I
think
it'll
be
fairly
clear.
It
just
gets
a
little
weird
with
things
like
I
mean
whether
if
you
do
the
new
the
new
naming
scheme,
unlike
let's
go
with
even
weird
that
just
the
quiet
right.
So
if
you
have
the
proxy
server
client
code
being
in
the
go
mod
for
API
server,
is
it
yo?
Is
it?
Is
it
27
and
that's
for
both
26
and
27.
E
C
I
would
my
suggestion
would
be
to
adopt
a
new
approach
for
the
new
releases
and
like
make
it
clear
in
the
readme,
and
if
there
is
any
issue
that
is
in
the
community
regarding
the
naming
scheme
for
the
old
releases,
then
we
sort
of
go
back
and
try
to
address
that.
But
if
there
is
no
issue
they
used
then
sort
of
we
move
forward.