►
From YouTube: 2020-12-02 meeting
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
D
D
D
Thing
there
is
a
overlap
between
this
and
the
tt
meeting.
Let
me
go
to
that
meeting
and
ask
everyone
to
join
this
for
this
discussion.
Initially,
I
will
be
back
in
one
minute.
Sounds.
C
G
F
H
Super
windy:
it's
super
windy
here
in
portland,
it's
very
possible.
His
power
got
knocked
out.
H
D
G
B
Okay,
I
just
kind
of
had
like
a
I
had
a
lot
of
questions,
but
one
of
the
ones
I
had
just
on
a
second
read
of
this.
It
sounds
like
we've
switched
over
from
versioning
each
signal
independently
and
that
there's
going
to
be
a
cohesive,
like
version
across
all
releases,
essentially
so
1
0
is
going
to
contain
the
trace
api.
The
metrics
api,
the
logging
api.
Eventually,
when
that
comes
in
like
all
of
these
things,
and
then
it
is
around
like
the
semantic
versioning
across
that
it
seems.
B
I
I
think
that's
probably
a
good
idea,
but
the
problem
that
I'm
seeing
is
that
if
you
have
different
life
cycle
states
of
one
of
the
signals
and
then
you're
you're
versioning,
that
as
though
it
is
a
stable
release
or
you're
versioning
it
as
though
it's
you
know,
progressing
in
in
backwards
and
compatible
changes
when
it
doesn't
have
backers
and
compatible
changes.
That
may
communicate
the
incorrect
thing
to
the
users
of
the
project.
If
that
makes
any
sense.
F
F
You
just
have
to
make
sure
that
whatever
goes
into
the
newly
released
version
is
a
no
change
for
the
metrics
right.
It
may
mean
that
you
have
to
do
some
branching
and
stuff
like
that,
but
incrementing.
The
version
number
that
does
not
necessarily
mean
that
all
of
the
signals
have
something
new
there
right.
It's
a
no
release
for
that
particular
signal,
which
I
think
is
fine
right.
It
does
not
contradict
with
the
sender
concept.
B
So
we'll
kind
of
I
I'm
a
little
worried
about
the
opposite
case.
I
think
I
think
the
case
that
you
just
outlined
makes
sense,
but
if,
if
you
go
and
you
add
the
metrics
api
as
a
stable
api
right,
the
idea
there
ted-
I
think
explained-
was
you
want
to
increment
a
major
version
at
that
point.
So
you
go
from
one
to
two
or
something
like
that.
Yeah.
F
I
think
I
I
don't
think
we
should
be
doing
that.
I
think
that
part
is
is
not
correct,
so
I
propose
we
do
it
slightly
differently.
Okay,
we
have.
All
of
the
signals
are
currently
on
zero
dot
x,
whatever
it
is
right,
we
make.
We
arrive
at
some
point
in
a
few
weeks
where
traces
are
good
enough
to
be
declared
stable.
We
make
1.0
release,
which
only
includes
traces.
It's
a
breaking
change.
We
increment
them.
You
increment
the
major
version.
F
Number
and
metrics
are
not
there
anymore,
so
it's
really
a
breaking
change,
regardless
of
what
we
do
in
the
traces
right
at
some
point,
when
the
metrics
are
ready,
you
make
a
minor
version,
release
1.1
or
1.5
or
whatever,
wherever
you
are
at
that
point,
and
now
you
add
the
metrics
to
that
right.
It's
a
minor
version
with
this,
because
you
don't
break
anything
in
the
traces
portion,
you're
just
adding
stuff
to
one
x
and
that
works
with
somewhere
right.
F
I
So
complete
yeah,
we
kind
of
just
jumped
in
a
little
bit
yeah
yeah
group
thing.
So
whatever
the
discussion.
B
F
Let
me
repeat
that
for
10
again,
I
think
the
the
the
question
is:
how
do
we
make
sure
that
the
version
numbers
for
the
signals
are
aligned?
And
what
do
we
do
when
we
need
to
make
the
very
first
release
of
each
signal
independently?
Here's
what
I
suggest
we
do
currently
all
of
the
signals
are
on
zero
point
x.
Whatever
it
is,
languages
have
different
numbers
right
now,
when
the
traces
are
ready.
We
released
1.0
right.
1.0
is
a
breaking
change
from
zero
point
x
and
it
only
includes
traces.
F
So
that's
why
at
least
that's
why
it
is
a
breaking
change
and
that's
why
it's
a
major
new
version,
new
major
version,
number
1.0.
We
continue
improving
traces,
maybe
release
1.1
1.2
whatever
at
some
point.
Metrics
are
now
also
ready
to
become
stable.
We
make
the
next
minor
version,
release,
1.3
or
1.4
and
add
metrics
to
that
package.
That's
only
a
minor
version
really
is
because
it's
an
addition
right,
nothing
breaks
there.
We
don't
need
to
do
a
major
version,
change
there
and
then
we'll
continue
doing
the
releases.
F
The
other
question
tyler
had
is:
what
do
we
do
to
keep
the
version
numbers
aligned
between
the
signals?
Let's
say
you
want
to
you
made
changes
to
the
traces
portion
only
and
you
want
to
make
another
release,
but
nothing
changed
in
the
metrics.
That's
fine!
You
just
increment
the
minor
version
number
and
make
a
release,
which
only
includes
something
additional
for
the
traces.
Nothing
changed
for
the
metrics
and
that's
okay,
that's
fine!
With
the
assembly.
F
You
may
need
to
do
some
branching
there,
because
you
may
have
made
changes
in
the
metrics
portion
which
are
not
ready
to
be
released,
but
that's
on
the
maintainers
right.
How
do
you
make
sure
that
whatever
changes
you
do
if
they
are
not
ready
to
go
to
the
mainline
release
right
branch?
Keep
them
on
the
on
the
sideline
branch?
Right?
That's
that's
only
maintainers!
I
I
have.
D
A
slightly
bit
different
approach,
but
it's
on
par
with
what
you
say
is
the
following.
I
think
we
should
keep
for
every
artifact
for
the
time
being
to
two
artifacts,
so
so
for
for
api,
for
example,
we
have
two
two
different
packages
or
artifacts
I'll
talk.
I
will
call
them
artifacts
because
I'm
slightly
more
familiar
with
java,
but
let's
say
that,
so
we
have
two
artifacts
another
pack
called
api,
stable
or
just
api
and
an
artifact
called
api
experimental
okay.
D
So,
right
now
we
can
say
that
everything
is
into
the
api
experimental
artifact
and
we
should
probably
move
everything
into
this
api.
Experimental
artifact,
which
will
always
be
on
zero,
will
never
be
on
on
any
other
version,
so
you
will
always
start
with
a
zero
that
will
continue
to
increase,
maybe,
but
you
will
always
be
on
on
version
zero
and
when,
when
something
is
declared
stable
and
we
are
ready
to
to
to
have
it
stable,
we
move
into
the
api
stable
package
artifact.
D
So
that
means
right
now.
Let's
assume
go
in
two
weeks
is
ready
to
release
the
the
tracing
part
of
of
the
the
things
will
create
the
package.
Slash
hotel
or
the
the
current
slash
hotel
package
will
include
only
the
stable
things
and
everything
else
will
go
into
a
slash,
hotel,
slash,
experimental
or
something
like
that.
A
different
artifact,
a
different
package
and
and
again
that
will
that
will
allow
us
to
to
continue
to
develop,
for
example,
logs
in
the
experimental
artifact
and
whenever
they
are
or
whatever
we
have
something
that
is
stable.
D
F
I
think
what
you're
saying
is
is
the
same
thing
right
right.
I
don't
see
how
what
you
say
is
different
from
what
I'm
just
proposing.
D
The
only
thing
that
is
different
is
keeping
this
experimental
artifact
around
and
releasing
it
for
people
if
they
want
to
give
a
try
to
the
experimental
api
and
we
give
a
try
to
the
mental
api
still
exists,
but
when
table
is
moving
the
the
non
experimental
artifact,
that's
a
possibility.
Again,
I
don't
know
if
everyone
is
happy
with
that,
but
that
that
is
a
reasonable
possibility.
F
F
I
The
idea
is
that
you
want
to
have
the
ability
to
remain
retain
avi
compatibility
right.
So
I
think
this
depends
on
language
what
that
kind
of
thing
means,
but
the
idea
is
if
we're
making
breaking
changes
to
metrics,
but
people
are
not
referencing.
The
metrics
api
they're
only
referencing
the
tracing
api,
then
the
packages
that
just
reference
at
tracing
api
won't
be
affected
by
any
compatibility
issues.
Changes
around
metrics
might
make.
So
that's
that's
kind
of
language
by
language.
D
Yeah,
muted,
the
other
approach
that
grpc
did
was
to
to
have
api
marked
as
experimental
and
and
allow
breaking
api
on
that.
Even
though,
is
not
fully
semver
compa,
like
they
don't
follow
fully
december.
They
have
this
convention
of.
If
this
api
is
marked
as
experimental,
it
can
still
have
backwards,
incompatible
changes,
even
though
you
don't
increase
the
major
version.
That's
another
approach
that
we
can
get.
D
F
I
Yes,
but
there's
a
difference
between
like
okay
now
this
thing
has
gone
from
a
lease
candidate
to
stable
if
you're
on
the
release,
candidate,
you're,
fine
and
then
now
it's
stable.
But
if
it's
like
from
release
candidate
to
stable,
we
moved
everything
into
a
completely
different
package.
And
now
all
your
code
is
broke.
D
I
think
indeed
this
does
not
allow
you
to
have
this
release
candidate
step,
but
is
that
very
important?
Is
that
the
goal
I
mean
without
without
this
release
candidate
step?
Whatever
we
talked
about
is
gonna
work,
it's
just
it's
just
maybe
maybe
maybe
we
can
have
release
candidate
at
a
minor
version.
So,
for
example,
for
example,
what
we
can
do
is
we
keep.
D
We
keep
still
keep
the
two
packages
and
at
one
point
when
we
are
ready
or
in
a
release,
candidate
phase,
we
move
metrics
to
the
to
the
stable
package
and
we
do
a
release
candidate
release
of
the
of
the
stable
one,
and
that
in
that,
at
that
point
everything
becomes
clear.
You
don't
mark
that
release
final
until
you,
you
finish
the
release
candidate
phase,
so.
F
I
So
so
to
just
hop
in
here
real
quick.
I
really
agree
with
what
what
tigran
has
been
saying
around.
We
moved
to
1.0,
but
everything
past.
That
is
a
minor
virgin
bunk,
even
if
we
end
up
making
some
small
breaking
changes
within
the
sdk
packages.
I
Our
overall
goal
is
to
keep
end
users
up
to
date.
We
want
end
users
to
feel
like
they
can
just
upgrade
to
the
latest
version
of
open
telemetry,
and
there
generally
won't
be
problems,
maybe
some
minor
things
they
have
to
do,
but
but
we
can
we'll
do
our
best
to
actually
make
it
know
things.
It's
not
that
we
don't
break
things,
it's
that
we
don't
break
the
api
and
we
try
our
breasts
not
to
break
the
constructors
or
the
configurations
in
plug-ins
and
sdk.
F
I
What
I'm
concerned
about
is,
if
we
say
literally,
everything
remains
like
avi
compatible
everywhere.
Like
that's
untenable
right,
I
don't
think
I
think
realistically,
when
working
on
the
sdk,
we
should
try
our
best
to
not
break
things
like
we
should
not
break
things
arbitrarily.
We
should
always
choose
to
not
break
things
if
that's
an
option,
even
if
that
means
we
have
to
take
on
some
legacy,
support
or
some
complexity,
but
hang
on,
but
there's
a
difference
between.
Let's
say
we,
let's
say
we
have
to
change
how
an
internal
sdk
interface
works.
F
I
Breaking
api
change
and
it
would
be
breaking
for
plug-in
developers,
but
if
we
are
also
keeping
contrib
and
everything
up
to
date
and
the
constructors
or
the
configurations
for
those
things
on
the
outside,
don't
change
the
end
user
would
not
notice
that
breaking
change
so
much
because
we
would
does
that
make
sense.
D
No,
no,
it
doesn't
makes
too
much
sense
for
me,
because
api
does
not
include
the
behavior
so
so
to
to
to
clarify
if
abi
from
the
definition
of
at
least
in
java
does
not
include
the
behavior.
So,
for
example,
what
I'm
trying
to
say
is
if,
if
you
change
the
the,
I
don't
know
the
the
not
the
default,
but
if
you
change
a
string
to
a
byte
every
inside
your
your
your
code
is
not
an
api
incompatible
chain.
So
so
so
the
the
sdk
and
you
point
it
correctly.
F
Why
this
why?
This
is
important
right,
I
believe,
the
so
that
everybody
has
the
same
understanding.
I
have
an
application
which
uses
two
libraries
which
are
instrumented
with
open
telemetry,
but
they
use
different
versions,
different
versions
of
the
api.
They
are
instrumented
using
different
api
versions
of
open
telemetry,
but
they
must
work
with
the
latest
version
of
open,
telemetry
sdk.
This
is
the
scenario
we
care
about
right
and
they
must.
D
F
It
should
compile
and
work
the
behavior
may
improve
in
some
ways
which
we
consider
a
non-breaking
change,
but
at
the
minimum
it
should
compile
and
should
work,
and
we
should
not
require
the
library
authors
to
update
their
code
to
compile
against
a
new
version
of
the
api
package
right
so
that
they
can
begin
using
the
new
sdk.
That's
that's
the
problem.
I
That's
api
requirements,
but
then
we're
also
saying
when
people
when
end
users,
also
somewhere,
they
bootstrap
the
sdk
and
whatever
plug-ins
and
other
things
that
they're
using
right
so
there's
a
part
at
the
beginning
of
their
program
when
they
init
the
sdk,
and
that
is
also
potentially
breaking
changes.
It's
not
nearly
as
important
in
my
mind
as
the
api
compatibility,
but
things
like
constructors
and
configurations
that
the
end
user
interacts
with
those
are
the
other
things.
If
we
just
move
those
things
around
without
thoughtlessly
that
that
causes
trouble
for.
F
I
Yeah
this
also
includes
contrib,
though
that's
what
I
want
to
point
out
right.
That's
that's
the
actual
surface
area
people
are
touching.
Is
there
they're
setting
up
these
plug-ins
right,
they're,
not
so
much
themselves
touching
the
internal
apis
like
the
plug-in
interface
themselves,
but
they
are
touching
the
plug-in
constructor
and
the
configuration
so.
D
Before
jumping
to
that,
because
it's
a
harder
problem
there,
because
there
it's
also
the
the
the
plugins
artifact
version
that
is
coming
in
place
as
well,
but
before
before
doing
that,
we
need
to
clarify
which
artifacts
do
we
care
we
care
about
api.
We
have
to
have
super
strong
guarantees
there
and
the
scenario
that
tigram
pointed
it
should
always
work
if
two
third-party
libraries
are
instrumented
with
open,
telemetry
api
and
they
should
be
able
to
run
on
the
latest
api
version
with
no
problems.
F
Version
api
apk.
D
D
F
That
is
compiled
using
an
old
version
of
the
api,
and
you
put
the
new
sdk
there.
You
compile
it
with
the
new
sdk
and
it
should
work.
That's
that's
more
complicated
right.
I
have
a
question
here.
Are
we
sure
that
we
want
to
provide
these
abi
guarantees
right
away
from
1.0
release,
or
we
want
to
give
us
more
time,
because
if
we
want
to
do
that,
provide
that
guarantee
it's
a
lot
more
burden
for
maintainers
right
now
to
make
sure
that
the
interface
between
the
api
package
and
the
sdk
package
is
absolutely
stable.
F
F
I
F
Way
between
the
api
and
this
and
sdk
you
cannot,
you
cannot
rename
classes,
you
cannot
add
parameters
to
functions
if
the
api
and
sdk
are
communicating
using
those
correct
cases,
correct.
F
D
F
D
F
H
Which
one
so
can
I
can
I
break
in
for
us
for
one
second,
we're
basically
out
of
time,
and
I
just
wanted
to
call
out
one
thing,
and
that
is
that
all
of
this
discussion
is
awesome
and
super
cool.
If
we're
going
to
be
changing
the
way
we
structure
our
apis
into
separate
packages
in
order
to
release
separately,
I
we
are
adding
at
least
a
month
before
we're
ready
for
1.0,
and
I
just
want
to
make
sure
that's.
F
C
I
don't
think
we
should
be
so
scared
of
major
version
bumps,
but
I'm
guessing
that
in
some
other
worlds,
communities
this.
That
is
actually
a
problem
so
that
that's
fine
white,
so
2.0
for
metrics.
D
Tristan
tristan
just
to
clarify,
what's
the
point
of
releasing
one
zero
tomorrow,
if
in
a
month
we
know
is
going
to
be
2-0,
there
is
no
point.
We
are
just
lying
to
our
users
that
they
can
use
this
stable
thing
and
in
a
month
we
will
break
them
each,
which
is
exactly
the
scenario
that
we
are
right
now.
If.
C
It's
actually
a
month,
then
yeah.
I
completely
agree,
but
to
me
it
feels
more.
Like
1.0
comes
out.
Tracing
is
stable.
You
can
move
to
2.0
when
you
need
metrics
and
that
won't
be
coming
out
for
many
months.
There's
not
a
month
away
thing.
J
Okay,
but
I
think
there's
there's
like
that.
Sorry,
I've
mostly
been
quiet
here,
but
I
guess
my
one
piece
of
input
there
is
that
people,
when
you
release
something
when
you
release
a
major
version,
people
expect
you
to
support
that
major
version
for
some
time
with
point
releases
and
additional
like
non-major
features
and
and
to
keep
the
two
branches
in
sync,
and
so
the
only
difference
is
metrics.
J
And
I
you
know
I
I'm
not
I'm
not
in
a
position
to
say
that
it's
only
one
month
for
metrics
or
two
months
for
metrics
or
two
years
for
metrics,
like
that's,
that's
for
the
you
know
for
the
group
to
figure
out
together
but
like
if
it's
literally
only
one
month,
then
I
would
agree
with
with
what
a
few
folks
on
the
call
are
saying
and
like
just
call
1.0
in
a
month.
But
I
realize
it's
a
slippery
slope
and
we've
been
saying
that
for
a
year
now,
so
I.
I
Think
we
have
to
figure
out
what
it
is,
we're
gonna
do.
First,
I
I
think,
let's
work
back
from
first
principles.
I
agree
with
john
that,
if
it
turns
out,
we
haven't
done
our
homework
enough
and
some
sigs
are
like
not
in
a
good
place
to
make
the
guarantees
that
we
want.
Then
we
have
to
go
to
bat
for
them.
But
let's,
like
honestly,
like
put
that
aside
a
little
bit
and
figure
out
what
it
is
that
we
want
in
the
long
term.
H
A
little
bit
different
ted,
and
that
is
that,
if
we
need
to
reach
like
do
a
massive
restructure
of
our
code
base
in
order
to
publish
separately
that's
going
to
be
an
extra
month
right.
That's
what
I'm
saying
not
that
we
can't
guarantee
like
within
a
couple
weeks
that
we
get
some
good
binary
backward
compatibility,
but
that
if
we
have
to
do
this,
restructuring
exercise
that
will
be
expensive
right.
D
It
is
very
clear
to
me
that
we
need
to
if
we
do
a
1.0.
It
should
not
include
matrix
yes,
because
because,
if
we
still
working
on
metrics
and
we
after
this,
we
release
1.1,
we
break
somewhere,
we
break
somewhere
because
between
1.0
artifact
and
1.1
artifact.
D
D
Branch,
that's
right,
that's
that's
what
I
was
seeing.
We
have
two
artifacts
a
stable
artifact
and
then
experimental
artifact,
and
the
only
thing
that
we
need
to
do,
for
example,
john
in
java,
would
be
to
move
the
metrics
api
into
a
different
artifact
called
api
experimental,
or
something
like
that,
and
that's
the
only
thing
that
we
need
there.
D
I
I
don't
know
that
we
need
to
move
it
into
a
different
package.
We
need
to
have
separate
branches
and
the
metrics
work
is
on
one
branch
and
it's
not
on
the
other
branch
right.
It's
not
that
it's
on
both
branches
and
it's
in
a
different
package
like
an
experimental
package,
that's
different
from
the
final
resting
place.
It's
going
to
go,
but.
C
D
Yeah
we
want,
we
want
to
still
releasing
that
for
for
people
to
play
and
to
for
us
to
play
with
that.
So
that's
why
I
was
thinking
you
still
need
to
to
have
that.
So
personally,
how
I
would
do
in
java,
for
example,
I
would
go
create
a
new
artifact
called
api,
experimental
or
unstable
api
unstable
move.
Only
only
the
metrics
part
and
still
depend
on
the
the
the
previous
api.
D
I
I
D
That's
very
simple:
that's
very
simple!
That's
very
simple!
You
can
do
that
and
I
was
telling
you
about.
Grpc
and
josh
from
google
can
tell
you
about
scala
where
they
did
exactly.
This
marked
something
experimental
in
the
in
a
in
a
stable
artifact
people
start
using
it
immediately
and
they
couldn't
make
any
breaking
changes
because
they
would
break
badly
the
abi
they
would
not
be
able
to
to
move
forward.
So
the
problem
is,
people
will
not
respect
the
label.
C
C
Captures
trace
so
there's
tracing
and
metrics
packages
that
can
either
be
one
can
go
to
1.0,
while
the
other
one
stays
at
0.1
and
then
there's
the
option
of
having
a
stable,
open,
telemetry
api
package,
along
with
a
unstable,
experimental,
open,
telemetry
api
package
right.
F
D
Yeah
but
but
they
are
marked
as
zero,
so
the
ones
that
are
not
stable,
they
are
marked
as
zero.
The
the
downside
of
that
I
mean
there
is
not
so
much
downside.
We
can
definitely
do
that.
The
the
only
problem
with
that
we
increase
the
number
of
artifacts
that
people
need
to
to
link
on
and
we
have
a
dependency
between
these
artifacts.
So
so,
for
example,
you
need
to
have
a
baggage
artifact,
a
complex
artifact,
a
tracing
artifact,
a
metrics
artifact
and
the
maybe
in
the
future.
D
Logs
artifact
may
not
be
a
problem,
and
this
will
perfectly
work.
As
tristan
pointed
my
solution
was
with
a
mindset
that
we
want
in
let's
say,
12
months,
when
all
this
will
be
stable
to
have
only
one
artifact,
but
that
can
be
solved
by
having
a
fake
artifact
that
just
includes
all
of
them
and
it
depends
on
all
of
them
and
people
say
api-all,
and
we
call
that
api-all,
which
includes
all
of
them,
that
that
is
a
reasonable
solution
as
well
tristan,
and
I
think
I
like
it
the
way
that
they
can
go
independently.
D
The
other
problem,
the
other
problem
that
this
proposal
has
is,
let's
assume,
let's
assume
right
now
you
are
having
tracing
1.0.
You
will
hit
1.5
when
the
matrix
is
also
becoming
stable.
Are
you
gonna
call
metrics
1.5
to
be
consistent
across
versions?
I
would
totally
recommend
that,
even
though,
even
though
we
didn't
have,
we
did
not
have
1.04
metrics,
I
will
recommend
you
start
with
1.5
for
metric,
so
that
so
that
it's
consistency
across
all
these
five
or
how
many
packages
we
have
in
the
api
on
the
version.
D
I
D
F
I
I
F
D
What's
happening
tigran,
I
wouldn't
want
to
try
that,
but
but
every
every
language
for
example.net,
I
think
they
should
do
whatever
is
canonical
for
them,
but
the
recommendation
from
the
tc.
I
really
like
what
tristan
pointed:
let's
have
different
packages
whenever
they
got
stable,
they
should
be
on
the
same
version,
all
of
them
when
they
are
not
stable
either
either
use
a
zero
dot
version
for
that
unstable
or
use
the
dash
alpha.
If
you
prove
in
your
ecosystem,
the
building
tools
know
how
to
deal
with
these
problems.
F
I
As
long
as
as
long
as
people
can
just
easily
import
and
get
the
correct
things
right,
like
that's
like
the
zero
dot,
whatever
branches
they're
still
only
going
to
be
expected
to
work
with
some
later
version
of
the
sdk
right
so
but
you're
right,
it's
probably
fine.
It's
probably
fine
that
everything's
either
on
a
zero
dot,
whatever
branch
when
it's
except
it's
experimental
and
then
it
just
goes
to
whatever
the
current
stable
branch
number
is
right.
F
D
D
So
that
way
that
way
the
package,
the
stable
packages
will
be
1.12
and
the
unstable
packages
will
be
0.12,
so
they
try
to
keep
the
the
miner
on
seeing
all
of
them
anyway.
This
is
a
the
next
level
if
we,
if
we
believe
this
is
useful,
we
we
can
even
do
this.
So
we
have
packages
on
one
point
x
and
the
rest
of
the
packages
are
on
zero
point
x
to
be
consistent
on
the
minor
version,
so
the
minor
kind
of
becomes
the
the
number
of
releases.
D
F
Go
ahead,
I
want
to
ask
this
one
more
time
guys.
Do
we
want
to
postpone
giving
guarantees
on
the
binary
level
so
that
we
make
1.0
release
earlier,
which
only
provides
guarantees
on
the
api
level,
which
means
that
you
have
to
recompile
your
code
with
newer
version
of
api
when
you
upgrade
to
newer
version
of
sdk,
I
think
it's
acceptable
for
the
first
couple
releases.
Yes,
if
it
buys
us
time
all.
I
Right
here
and
I've
actually
absolutely
run
into
this
with
c
plus
plus
even
in
open
tracing,
and
I
agree
with
you
that
the
it's
much
more
straightforward
to
say,
recompilation,
api
compatibility
than
abi
compatibility
in
specific
languages,
crazy
things
can
make
things
no
longer
be
api
compatible
and
it's
very
specific.
D
Let's,
let's
do
this
language
by
language,
every
language
knows
better
their
users
and
how
users
are
are
used
to
these.
I
do
agree
in
c,
plus
plus
people
tend
to
recompile
everything,
no
matter
what
so
that's
a
different
story,
but
let's
do
this:
let's
let
let
the
the
every
language
decide
whatever
they
want
to
do
on
this
yeah,
because
I
I
feel
like
dot
net,
has
a
strong
requirement
because
they
they
have
an
ecosystem
that
goes
in
some
ways.
D
F
D
Does
this?
Does
this
clarify
everyone's
questions?
D
H
So
my
one
month
by
the
way
is
conservative
because
I
always
like
to
be
to
give
conservative
estimates
on
things,
and
I
also
just
know
that
if
we
have
to
figure
out
tooling
for
doing
different
versions
for
different
artifacts
and
restructuring,
it
will
be
we'll
take
time
to
get
that
all
correct
and
right
and
published
we're
already.
We
every
release.
H
We
have
trouble
with
getting
things
published
properly,
even
with
things
not
changing,
but
I
will
say
that
I
think
like
if,
for
example,
spring
sleuth
wants
to
use
open
telemetry,
they
are
going
to
require
abi
binary
compatibility
basically
forever
at
1.0.
H
I
D
I
Yeah,
I
don't-
I
don't
know
enough
about
java
to
know
what
what
makes
a
lot
of
trouble
versus
what
what
doesn't,
if
that
that
makes
us
that
allows
us
to
have
our
cake
and
eat
it
too,
where
the
sub
packages
are
abi
backwards
compatible.
But
you
have
an
all
package
that
end
users
can
use,
but
spring
sleuth.
Doesn't
that
seems
fine.
Otherwise,
it
seems
like
an
unnecessary
extra
burden
to
split
the
packages
up
if
everyone's
just
going
to
use
a
combined
package
that
also
has
to
be
avi
compatible.
D
D
A
I
That's
a
very
hard
problem.
In
fact,
we
want
the
opposite.
We
want
to
do
as
much
work
as
possible
to
ensure
people
stay
up
to
date
with
the
latest
version,
which
is
also
why
I
favor
sticking
to
like
minor
version
bumps
after
1.0,
because
what
we
want
to
convey
to
people
is
like.
I
You
should
feel
confident
that
you
can
just
upgrade,
and
you
should
do
that
in
exchange
for
that
we're
not
going
to
have
old
versions
that
we
support
and
back
port
things
too,
because
we're
going
to
make
it
easy
for
you
to
upgrade
that
avoids
some
hell
in
the
future.
I
think
I
don't
even
can't
even
wrap
my
head
around
how
we
support
multiple
versions
of
this
perfect.
I
think.
I
I
do
I
can
make
another
pass
at
this.
Do
people
have
any
availability
this
afternoon?
I
can
try
to
get
a
draft
out
and
sent
over.
I
don't
know
if
you
want
to
talk
more
by
then,
but
let's,
let's
at
least
schedule.
Another
meeting
is
sometime
this
afternoon
available
for
people
like
if
I
just
throw
2pm
pacific
out
there.
Can
people
do
that.
I
I'm
not
available
at
two
one.
One
o'clock
would
work
better
for
me.
You
can
do
one
o'clock.
What
about
do?
I
hear
one
o'clock
one
o'clock.
Anyone
else,
yeah
works.
B
B
I
Jam
it
out
right
now,
I'll,
publish.
K
I
The
spec
getter
channel
and
I'm
throwing
a
media
on
the
calendar
meeting
on
the
calendar
right
now.
So,
okay,
awesome
thanks!
Sarah!
Thank
you
all.
I
appreciate
you.