►
From YouTube: 2023-03-22 meeting
Description
cncf-opentelemetry meeting-2's Personal Meeting Room
A
A
B
Yeah,
it
looks
like
we're
just
waiting
on
Anthony.
Oh
I,
spun
up
a
dock
to
kind
of
capture
things
here:
I'm
gonna,
post
it
in
chat
Aaron's,
getting
his
headphones.
B
But
yeah
it
just
kind
of
covers
I.
Think,
like
our
conversation
earlier,
Ted
with
actually
I
have
another
question
on
it.
But
questions
but
I
just
want
to
like
capture
that
and
then,
when
Anthony
gets
here
and
I
think
he
was
finishing
up
a
meeting
right
before
this.
So
maybe
just.
A
B
B
A
B
A
D
Lovely
I
can't
hear
you
guys,
so
you
can't.
A
B
D
B
Yeah
seems
to
seems
to
always
work.
I
did
oh
man,
pings
Anthony,
but
we
are
waiting
on
I'm
running
a
bit.
Late
would
be
screenings
over
shoot.
B
Yeah,
it
sounds
like
there's
other
meetings
running
over
well,
okay,
I
mean,
ideally,
we
would
have
them
here.
C
Yeah
but.
B
Okay,
I
put
this
down
for
30
minutes,
but
if
we
wait
too
much
longer,
I
don't
think
we
can
fit
it
in
30
minutes.
So
if
we
can
kind
of
extend
beyond
the
time
when
Anthony
does
show
up,
I
think
that's
fine,
and
maybe
we
could
just
kind
of
jump
in
right
now
and
then
maybe
kind
of
do
a
resync
I've
got
a
lot
of
this
captured.
B
So
what
yeah
I
guess?
What
do
you
guys
want
to
do
you
want?
We
can
just
wait
till
Anthony
is
available
and
then
jump
back
on
the
call
or
we
can
I
can
go
over
this
once
and
then
do
it
twice.
B
Yeah
yeah
one
of
those
who
knows
you
know
if
that
other
person's
gonna
stop
talking
kind
of
thing,
I'm
guessing
but
yeah,
that's
all
good,
but
yeah
speaking
of
Meetup
set.
Are
you
gonna,
try
to
do
another
one
or
is
that
kind
of
just
shot
at
this
point,
I.
C
Hope
so
you
know
Rhys
the
person
who's,
organizing
them
I
should
follow
up
with
her
to
see
see
what
the
deal
is.
Yeah
I
couldn't
tell.
If
it
was,
it
didn't,
seemed
like
it
was
an
open,
Telemetry
specific
meeting
yeah
like
we
were
maybe
piggybacking
off
of
some
other
thing.
So
I
don't
really
know.
B
I
think
it
was
going
to
be
one
if
you
showed
up
but
yeah
I,
think
you're
right,
yeah,
a
Dev
Meetup
or
something
yeah.
C
But
it
would
be
cool
to
have
like
an
open,
Telemetry
or
observability
specific
meet
up,
I.
Think.
B
I
agree:
I
was
thinking
about
asking
that,
like
the
only
thing
we
need
is
just
some
place
to
host
it
right
is
the
only
you
know,
yeah
issue,
that's
true,
but
I
mean
if
yeah,
if
New
Relic
wanted
to
host
it
that'd
be
cool.
We
could
also
I
mean
like
if
there's
only
15,
people
like
we
could
just
go
to
a
bar
or
something
too
right.
D
Yeah
one
of
the
the
bigger
like
devops
groups
here
they
haven't
been
able
to
rebound
after
the
pandemic.
So
now
it's
like
every
other
month.
They
just
do
a
drinks
with
Cloud
Austin
and
one
of
the
the
many
bars
that
are
around
here
and
last
night.
We
had
one
last
night
and
it
got
about
25
30
people
showing
up
so
maybe
it's
time
to
to
reinvite
and
and
see
if
we
can
find
the
space
again.
B
B
C
Yeah
I,
don't
know
like
if
we're
gonna
just
meet
up
for
like
drinks
and
dinner,
then
like
like
Hotel
specific,
is
totally
cool
like
like
I,
feel
like
there's
like
beer
holes
with
big
tables.
There's
also
like
plenty
of
like
food
cart,
pods
yeah
that
we
could
hit
up
that
would
accommodate
us.
I
mean
if
it's
Hotel
specific,
it's
probably
like
what
like
10
of
us
or
something
so
yeah.
B
I
think
like
it's,
you
me
Jason,
Plum,
Trask
and
then
I
think,
there's
I,
don't
think.
There's
anybody
else
in
the
Portland
area.
Well,
so
there's
no
other
like
contributors,
but
like
I
think
that's
also
something
that
could
be
cool
like
would
be
ideal
is,
if
you
had.
Users
came
out
that,
like.
C
B
B
B
Works,
yeah,
no
worries
cool,
so
I
didn't
want
to
waste
too
much
time
on
this,
but
I
also
like
have
the
skin
for
a
half
hour.
Anthony
I,
don't
know
if
you
have
anything
at
the
end
of
the
half
hour,
but
it
may
run
a
little
long.
B
Okay,
so
then,
maybe
just
jump
in
then
so
I've
got
this
stock.
I
posted
it
in
the
it's
in
the
meeting
invite
and
it's
in
the
chat
here.
I
can
post
it
again
Anthony
if
you
don't
have
access
or
another
link,
nope.
B
You,
okay,
perfect,
so
on
the
agenda.
I
just
wanted
to
talk
about
the
API
stability.
I
was
talking
with
Ted,
async
and
slack
just
a
moment
ago
about
this
major
version,
pump
idea
and
then
follow
it
up
with
like
this
metrics
API
future
proofing.
So
I
think
this
is
going
to
really
lead
the
discussion
about
this.
So
I
wanted
to
start
there
pause.
Is
there
anything
else
we
wanted
to
talk
about
on
the
agenda.
B
Okay,
cool
well,
then
I
will
jump
in.
So
this
is
kind
of
a
rehash
of
Ted
and
Maya's
discussion.
I
wanted
to
kind
of
get
some
documentation
of
like
what
we
talked
about
just
so
that
we
can
kind
of
cover
here.
So
the
idea
is
like
that
came
to
me
asking
me
like.
So
what?
What
is
the
downside
of
doing
a
major
version
bump
for
go?
B
You
know
using
like
the
standard
go
parlance
for,
like
you
know,
a
V2
with
it
being
a
new
package
and
then
releasing
it
as
like
a
2.0,
and
so
I
came
up
with
these
identified
issues,
and
you
know
one
of
the
things
is
like
instrumentation.
Authors
are
going
to
need,
update
their
instrumentation
they're
gonna
need
to
switch
from
the
V1
switch
their
package
import
path
to
the
V2
to
start
using
the
V2.
As
long
as
there's
overlaps
there,
like
the
compatibility
of
those,
is
going
to
be.
B
You
know
the
main
question
of
this
whole
conversation,
but,
like
you
know,
it
should
be
a
Ford
facing
like
API,
where
additions
are
added,
let's
just
kind
of
say
that
so
that
upgraded
path
should
look
pretty
seamless.
B
You
know
it
is
a
positive
action,
so
if
you
have
abandoned
instrumentation
like
it's,
you
know,
you're
gonna
need
a
fork.
It
essentially
to
try
to
do
the
upgrade,
but
it
should
still
remain
compatible.
B
I
think
with
the
old
SDK,
because
this
I
think
is
kind
of
the
key
thing
is
that
sdks
will
need
to
be
compatible
with
all
of
the
API
versions
and
I
say
that
just
because,
if
you
have
like
you
know,
sdk1
V1
and
SDK
V2
but
V2
is
you
know
only
compatible
with
the
V2
API,
then
the
end
user
has
to
be
able
to
set
up.
They'd
have
to
set
up
two
sdks
right.
B
So
if
their
instrumentation
is
for
both
the
A1
API
or
V1
API
and
the
V2
API,
then
they
need
an
SDK
for
the
V1
portion
of
their
instrumentation
and
a
V2
portion
of
their
instrumentation.
Those
don't
share
State
at
all.
Those
don't
like
coordinate
at
all
like
they
could
potentially
use
the
same
exporters
but,
like
that's
a
whole
other
thing
right
like
because
technically
I
think.
Actually,
our
export
locking
doesn't
work
across
providers
right
now,
but,
like
things
like
probabilistic
sampling
like
where
you
wanted
to
maintain
state
would
have
to
be.
B
We
thought
at
the
least,
but
I
mean
there's
going
to
be
severe
problems,
I
think
from
the
usability,
but
as
well
from
like
the
technical
side
of
of
like
having
our
sdks,
not
support.
All
of
the
apis
right,
so
I
think
that's
something
that.
B
Yes,
and
that's
yes,
you
are
you
are
seeing
where
this
conversation
is
going
right,
because
that's
that's
a
really
big
question
is
how
does
the
spec
evolve
and
so
I
could
talk
about
it,
but
I
also
know
Ted's
really
passionate
and
I
will
capitalize
the
hell
out
of
this
conversation,
if
I'm,
let
alone
so
maybe
I'll.
Just
let
Ted
kind
of
talk
about
like
what
his
thoughts
on
the
spec
Evolution
should
be
yeah.
C
Right,
like
our
rules
are
you
know,
we
can
only
make
additive
changes
to
our
instrumentation
apis,
because
to
do
anything
else
would
break
existing
instrumentation,
but
the
go
Community
gets
feisty
around
adding
you
know
certain
kinds
of
additive
changes
should
to
like
interfaces,
for
example,
should
be
a
new
package
right,
like
a
new
module
with
a
major
version
bump,
and
so
I
was
trying
to
think
about
like
what
the
downsides
would
be,
and
it
seemed
like
the
only
if
we
just
kept
on
with
what
we
were
currently
trying
to
do,
which
is
just
make
additive
changes.
C
But
every
time
we
made
an
additive
change
that
the
go
Community
considered
a
major
version,
but
we
did
it.
It
seems
like
the
only
extra
thing
that
would
come
along
with
that,
like
instrumentation
authors
wouldn't
have
to
could
still
use
the
old
packages.
C
The
SDK
would
just
have
to
support
the
latest
API,
because
all
prior
apis
are
just
like
a
smaller
subset
of
the
latest
one,
and
the
only
real
wrinkle
would
be
when
you
register
providers
right
you'd
have
to
register
with
the
V2
the
V1,
the
v0
providers,
but
that
could
be
done
internally,
so
the
V2
provider
could
just
then
register
you
with
the
V1
provider
and
the
V1
provider
can
register
you
with
the
v0
provider.
Well,.
C
Might
be
zero,
it
would
my
so
my
understanding
is
that
that
that's
like
not
a
problem
with
with
the
way
go
modules
work
since
they're,
just
essentially
separate
packages
pulling.
E
Yeah
I
believe
it's
explicitly
expected
to
be
able
to
implement
a
newer
version
in
terms
of
an
older
version,
or
vice
versa.
Yeah.
C
Yeah,
so
so
the
the
hope
would
be
that,
from
the
end,
user's
perspective,
nothing's
really
different,
except
you
know.
If
they
want
to
use
a
new
API
feature,
they
would
have
to
to
upgrade
to
the
version
of
the
API
that
had
that
feature,
but
otherwise
they
wouldn't
have
to
touch
their
code,
so
it
it
seems
like
it
would
work.
C
This
could
be
a
way
to
to
fall
in
line
with
the
with
the
go
communities
expectations
around
versioning.
C
We
would
still
be
restrictive,
though,
like
we,
we
still
would
have
a
rule
that,
like
you,
can't
a
major
version
bumps
to
an
API
package,
have
to
be
additive
only
right,
like
that's
our
rule,
which
gets
into
I
think
Tyler's
other
question
which
he
he
was
wondering
whether
or
not
the
spec
would
ever
come
out
with
like
a
V2
of
tracing
and
create
some
confusion
there,
and
what
I
was
telling
him
over
slack
is
like
that's,
that's
not
actually
something
we're
ever
gonna.
C
Do
it's
not
feasible
to
ever
make
a
breaking
change
to
one
of
our
instrumentation
apis.
If
we
ever
came
up
with
some
newfangled
V2
tracing
like
like
just
printing
2.0,
totally
new
thing,
that's
just
completely
incompatible
with
our
current
thing.
That
would
have
to
be
literally
like
a
whole
separate
signal,
so
it
wouldn't
be
tracing
2.0.
C
You
know
go
tracing
package
and
what
the
hell
does
you
know
that
mean
so
so
I
think,
just
from
the
different
ways
of
just
it,
the
more
we
talked
about
it,
the
more
reasonable
it
seemed
to
maybe
move
to
this.
C
This
major
version
bump
way
of
doing
things
for
for
go
modules
and
the
API
it
seems
like
that
would
like
there'd,
be
a
little
bit
of
extra
pain
for
us,
because
you
know
every
provider
would
just
have
to
have
an
extra
line
which
just
registers
with
the
the
older
provider,
but
otherwise
it
seemed
like
it
would.
It
would
work
and
make
the
community
less
cranky
with
us
every
time
we
we
added
a
method
to
the
API,
so
I
just
wanted
to
know
what
you
guys
thought
about
that.
E
A
E
C
That's
the
clarification
we
can
I'm
totally
down
to
make
that
clarification
in
the
spec,
because
the
Practical
reality
is
that
you
know
instrumentation
is
for
life
right,
like
you
know,
actually
actually
removing
something
from
our
instrumentation
API.
Once
it's
out,
there
is
like,
like
it
doesn't
matter
that
we
can
say.
Oh,
we
issued
a
major
version.
Number
we've
just
like
we're.
If
we
do
that,
like
that's
just
the
reality
right,
like
we've,
we've
ruined
Christmas
for
everybody,
so.
A
C
Can
make
that
that
clearer
in
the
the
spec?
There
is
like
a
section
on
on
versioning
and
I'm
happy
to
to
go
in
and
clarify
that
like
well.
C
E
I
mean
that's,
that's
a
restriction
we
can
put
on
ourselves,
but
I,
don't
think
it's
an
inherent
restriction
if,
like
if
the
the
go
API
gets
a
new
major
version,
we
can
absolutely
remove
methods
in
there
and
it's
not
going
to
break
anything.
It's
that's.
That's
exactly
how
major
versions
are
intended
to
function.
E
B
But
if,
if
we
change,
that
would
be
where
the
problem
comes
in
right
so
say
we
changed
the
method,
signature,
which
is
totally
valid
for
a
go.
Pager
version
release
but
like
say,
span
set
attributes
now,
except
a
slice
instead
of
areatic
arguments.
Rightly
you
can't
overload
the
method
so
like
then,
then
it's
an
impossible
Conflict
at
that
point.
Yes,.
C
I
mean
you
could
probably
like
use
shims
and
stuff
if
you
wanted
to
make
minor
API
changes,
but
at
the
end
of
the
day,
you're
gonna
have
one
SDK
and
it
has
to
support
all
prior
versions
of
the
instrumentation
API,
whether
we
call
the
major
versions
or
minor
versions
like
it
doesn't
matter
right
like
we've.
So
we
would
have
to
be
clear
that
this
isn't
like
carte
Blanc
to
to
just
drop
support
for
old
instrumentation.
C
C
A
C
The
expectation
and
the
this.
A
C
But
there
is
like
an
upgrade
dock
that
makes
it
clear
that,
like
end
users
are
we
want
a
world
where
all
our
end,
users
are
on
the
latest
version
of
the
SDK,
which
means
the
SDK
can't
ever
drop
support
for
old
apis,
and
it
also
can't
like
break
plug-in
interfaces
like
sharply
right
like
like
you
can
introduce
a
new
plug-in
interface,
but
you
have
to
support
the
old
plug-in
interface
long
enough
for
plug-in
authors
to
migrate
over
to
the
new
interface.
C
You
don't
want
end
users
to
be
in
a
situation
where
they're
like
I
want
to
upgrade
the
SDK,
because
I
have
instrumentation
that
uses
like
a
new
API
and
so
I
need
to
go
to
like
a
new
SDK
version,
but
I
can't
because
the
SDK
authors
broke
the
plug-in
interfaces.
So
these
plugins
I
defend
on
like
don't
work
with
the
new
SDK.
So
I
have
a
dock
that
has
that
written
down
as
an
Otep
I
can
send
that
to
you
guys
and
we
can
move
that
stuff
into
the
spec,
but
I.
B
Think
I
added
it
in
the
the
dock
being
shown
here.
This.
C
Okay,
147
upgrade.
C
B
Yeah
I
think
that's
I,
think
that's
usable
and
like
so
I
just
wanted
to
like
kind
of
reiterate,
like
I,
think
to
Ted's
Point
like
I.
Think
that
one
we
need
to
clarify
the
specification
and,
like
you
know,
make
it
clear
that
everyone
understands
what
we're
talking
about
in
versioning
compatibility
like
the
the
current
spec
can't
have
things
removed,
surface
area
or
the
signal,
and
it
can't
have
things
changed,
only
added
to
it
and
then
I.
B
C
Yeah,
the
SDK,
you
can't
make
changes
to
the
API
that
make
it
impossible
for
the
SDK
implementing
the
new
API
to
not
be
able
to
implement
the
old
one
right.
You
have
to
be
able
to
pass
these
providers
down
down
the
chain.
E
C
A
it's
the
same
situation
that,
if
you
know
someone
is
using
a
new
instrumentation
like
it's
not
going
to
work
with
an
SDK
or
an
implementation
that
doesn't
hasn't
been
updated.
However,
the
where
this
the
bonus
I,
think
that
we
get
the
problem
go
users
have.
The
concern
is
like
what
if,
for
some
reason,
they
are
they're
implementing
an
old
interface.
We
would
no
longer
be
creating
a
compilation,
error
or
like
a
runtime
error
if
they
were
doing
some
Dynamic
casting
or
something
like
those
are.
C
Those
are
always
like
the
fears
and
concerns
people
had
with
us
adding
methods
to
interfaces
and
calling
it
a
minor
version
bub,
and
so
this
would
actually
solve
that
for
people
we
would
no
longer
be
breaking
someone
who
is
around
with
one
of
our
interfaces
for
some
reason.
C
D
C
There
is
a
catch,
I
guess,
there's
a
catch
here,
which
is,
you
could
have
instrumentation,
that's
bumping
to
V2
right.
So
you
add
a
new
instrumentation,
but
you
don't
change
your
startup
code.
Maybe
this
is
like
the
one
gotcha
here.
You
don't
change
your
startup
code,
so
you're
still
just
even
though
you've
upgraded
your
even
though
you've
upgraded
your
SDK.
If
your
startup
code
is
just
registered
with
the
V1
provider,
then
all
of
that
V2
instrumentation
is
going
to
be
no
Ops,
so
that
is
actually
a
gotcha
right.
B
Instrumentation
actually
get
the
implementation
of
the
Tracer
provider.
It's
either
going
to
be
through
the
global
or
explicitly
passed
in
Via
an
option
right,
and
so,
if
you
upgrade
that
instrumentation
Library,
you
then
have
to
also
pass
in
a
new
parameter
and
that
parameter
type
has
to
match.
Otherwise,
it's
not
going
to
compile
sure.
E
But
it
has
to
be
a
tracer
provider
right
and
the
Tracer
provider
has
one
method
and
I:
don't
expect
we're
going
to
be
adding
new
methods
so
well,
no
Tracer
provider
is
going
to.
B
E
Then
I
think
we're
back
to
adding
private
methods
to
the
interfaces
and
needing
to
yeah
includes
those,
because
if
you
have
a
an
object
that
has
a
tracer
method
on
it,
that's.
B
A
yeah
it's
equivalent
instance
interface.
Implementation
is
like
well.
A
B
B
B
C
No,
but
it's
when
you,
you
have
your
V2
Tracer
provider,
like
you
register
right
I
have
my
V2
Tracer
provider,
which
is
an
implementation
and
I'm,
registering
it
with
the
V2
API.
So
that
thing
is
going
to
be
spitting
out.
V2
API
interfaces
right
when
you
Regis,
when
that
also
gets
registered
with
the
V1
through
those
interfaces,
it's
going
to
be
spitting
out,
V1
stuff,
so
I
think
it
works.
The
only
gotcha
is
like
if,
in
your
startup
code
right,
you
are
explicitly
registering
with
a
V1
with
the
V1
API.
C
E
B
B
E
C
A
B
D
D
D
B
Yeah
I
think
I
think
Aaron's
right,
but
again
this
may
be
something
kind
of
a
midpoint
because
it
can
be
solved
just
by
looking
at
actual
code
and
writing
something
really
quick,
but
yeah
I
think
I
think
it's
it's
an
open
question
I
think
is
something
I
don't
want
to
get
too
bogged
down.
Yeah.
B
Also,
this
other
point
as
to
like
you
know,
hear
like
just
in
this
situation,
where
you
have
the
global
right
like
I
was
thinking
about
this
earlier,
like
I
told
Ted
like
this
is
possible.
We
could
do
this
without
too
much
of
an
issue,
but,
like
you
know,
if
you
have,
you
know
this
existing
saturation
provider
in
the
global
world,
except
some
sort
of
Tracer
provider
like
this
sort
of
upgrade
or
change
to
the
functions,
function
signature
at
the
global
level.
This
is
like
the
hotel
package
like
it's,
it's
not
it's
not
compatible.
B
D
B
C
B
Okay,
I'll
I
just
want
to
make
sure.
Then,
if
we're
going
to
protest,
I
will
capture
this
question.
The
question
from
before
was.
C
C
B
Okay,
cool
all
right,
I
think
you're,
right,
Aaron
and
Anthony.
If
you
would
stay
I
still
think
we
have
like
a
little
bit
more
to
discuss
like
in
in
light
of
this
around
the
metrics
API
I
just
wanted
to
like
sync,
with
y'all:
okay,
cool
thanks,
Ted,
hey
see,
ya,.
D
B
E
B
I
I
think
that
I
think
it's
tractable,
but
you're
right
I
do
think.
I
wanted
to
include
that
as
like,
there
is
going
to
be
a
maintenance
burden.
Personally,
I
am
happy
to
support
a
little
bit
more
to
satisfy
go
compatibility,
guarantees
for
the
community,
but
you
know
if
it's
going
to
be
exponentially
more
that
that
could
we
might
want
to
think
about
tooling
or
something
like
that?
Well,.
E
And
part
of
a
may
also
depend
on
how
often
these
changes
happen
and
how
many
versions
We
need
to
support,
which
also
gets
too
I.
Think
the
the
other
thing
that
may
not
be
called
out
here
is
user
confusion
or
the
potential
for
user
confusion.
As
we've
got
several
major
versions
of
the
API,
which
one
do
they
need
to
use
to
get
a
particular
spec
version?
How
do
they
know
that
now.
B
I
think
that
the
answer
is
always
the
latest,
but
I
I
want
to
I.
Think
you're
right
I
think
we
need
to
document
that
just
because
I
think
there's.
We
need
to
make
sure
it's
clear,
okay,
cool.
So
all
right.
That
being
said,
I
think
that
there's
still
two
unknowns
here
and
we
need
to.
B
We
need
to
address
them
because,
like
this
is
a
I,
don't
know
if
it's
a
deal
breaker
but
I
think
it's
close
to
it
close
enough
to
a
deal
breaker
like
if
we
can't
have
a
good
answer
to
these,
then
like
we're
gonna,
have
a
problem
because
I
think
yeah
go
ahead.
B
Oh
go
ahead,
so
yeah
because
I
think
I
think
like
see
you
know
if
this
is
going
to
be
equivalent
to
just
providing
you
know
private
methods
and
having
runtime
panics,
because
you
know
interface,
satisfaction
isn't
like
is
somehow
not
baked
in
and
like
there's
gonna
be
like
there's
gonna
be
underlying
problems
and
we
we
might
want
to
I,
don't
know
if
we
want
to
pump
the
brakes,
but
I
think
I
think
we
might
want
to
think
about
this
a
little
bit
more.
So
I
think
we
need
to
prototype
this.
B
B
This
is
blocking
the
next
release
candidate,
which
is
blocking
our
stable
metrics
API
timeline.
So
I
wanted
to
like
prioritize
and
have
a
meeting,
but
it
seems
like
there's
an
open
issue
here
to
like
dive
into
this.
D
This
kind
of
issue
before
and
I
think
I
I
put
it
in
the
issue
that
I
created
about
the
whatever
sorry
my
brain
is
kind
of
right,
ad
links,
ad
links
right,
so
there's
a
repo
there
and
I
added
just
a
little
bit
this
morning
to
do
the
Nowak
implementation.
That
I
was
suggesting
at
the
tail
end
of
that
conversation,
where
we
don't
change
the
API
at
all.
We
don't.
D
We
don't
have
private
links,
private
methods
that
force
it,
but
you
just
have
a
no
op
implementation
embedded
in
the
SDK.
B
We
talked
about
this
last
week
at
the
sign
meeting
as
well
like
that's
where
this
kicked
off
this
issue,
this
issue,
the
explosive
no
app
implementation
like
I,
mean
just
to
kind
of,
like
recap
like
this-
is
broken
down
into
the
two
really
two
ideas
being
shown
here.
B
Right
one
is
that
we
provide
some
sort
of
like
default,
Behavior,
whether
that's
a
no-op,
whether
that's
a
logging,
no
op,
whether
that's
you
know
it's
some
sort
of
default,
behavior
that
any
sort
of
implementation
would
actually
Implement
and
then
the
second
idea
that
comes
from
this
is
also
like.
B
B
Explicit
choice
right
at
the
start,
right
like
they
can't
implement
the
interface
without
embedding
the
interface
or
embedding
a
no-op
right,
but
yeah
there's
a
lot
of
a
lot
more
here,
I'd
recommend
reading.
But
the
problem
also.
B
Like
this
requires,
you
know
it
changes
a
compilation
error
to
a
runtime
Panic.
If
they
decide
to
you,
know
embed
the
interface
or
it
changes
the
compilation
error
to
a
no-op
which
may
be
incorrect
Behavior.
You
know
not
doing
something.
Maybe
incorrect,
so
I
think
that's
a
problem.
You
know
that's
not
shared
by
just
not
doing
anything.
B
B
That's
also
proposed
I
think
this
is
a
third
Anthony
I'm
interested
to
hear
your
thoughts
on
this
art,
but
it
looks
something
similar
to
this.
Where
there's,
instead
of
embedding
the
private
method
directly,
you
have
another
interface
with
that
private
method
and
that's
embedded
in
the
actual
media
provider.
B
What
this
does
is
it
allows
you
to
choose
in
your
implementation.
You
can
embed
the
no
op,
you
can
embed
the
meter
provider
interface
or
you
can
embed
this
meter
provider
key
and
what
this
means
is.
If
your
implementation
doesn't
actually
implement
the
methods,
it
would
still
be
a
compilation,
error.
A
B
Think
I
think
this
all
kind
of
goes
out.
The
window,
though,
if
we're
going
to
just
increment
the
the
major
version
I'd
rather
not
do
these
like
weird
things
here,
if,
like
the
end
goal,
is
like
well
actually
what
we're
going
to
do
is
we're
going
to
do
a
major
version
bump.
So
don't
worry
about
any
of
this.
E
B
Still
providing
the
no
op
so
that
you
could
embed
it
and
like
if
you
really
want
to
just
like,
go
all
out
and
be
like
I,
don't
care
like
just
embed
it
like
in
case
I,
screw
something
up
like
or
actually
for
ease
of
use.
Right,
say
you
want
to
do
a
streaming
API
and
you're
like
yeah.
Technically
I
need
to
implement
all
these
other
things,
but
I'm
not
gonna.
B
D
Though
I
would
recommend
that
we
do
that
in
our
SDK,
just
in
general
that
we
embed
our
no
op
I.
E
Really
don't
think
we
should
do
that.
No,
that's,
not
a
bad
idea,
absolutely
not
that
that
goes
very
much
against
our
general
guideline
to
either
fail
fast
or
not
at
all,
and
the
fastest
you
can
fail
is
a
compilation
time.
B
Lot
of
sense,
if
your
SDK
is
developed
outside
of
the
API,
because
you
know
say
that
you're,
like
a
vendor
and
you're
in
your
own
repo,
like
there's,
no
guarantee
that,
like
there's
going
to
be
a
cohesive
release.
That
includes
your
fixes.
But
we
always
have
a
couple
like
our
build
tools,
guarantee
that
our
SDK
is
compatible
with
the
API
as
we
release
it.
C
B
Then
we
forget
to
actually
update
the
SDK.
So
then
we
just
ship
something
that
compiles
with
the
SDK
that
doesn't
know
out
for
the
ad
link,
like
that's
not
like
currently
right
now,
if
you
add
a
link-
and
we
add
that
method
to
the
span-
it's
not
going
to
be
able
to
ship
because
the
build's
not
going
to
complete.
B
D
But
I
think
the
more
Insidious
thing
is,
if
we
add
links
to
the
API
and
a
user
comes
along
and
picks
a
new
version
of
gen,
or
you
know
some
30
party
argument
that
upgrades
the
API
past,
where
their
SDK
is
now
they're.
Getting
a
breaking
change
in
a
different
dependency
than
what
they're
updating
yeah
but
I
mean.
A
B
This
is
this
has
been
the
entire
argument
we've
had
since
the
dawn
of
the
project
about
how
we
want
to
do
version
and
compatibility
right
like
this
is
what
we
were
talking
about,
I
think
last
two
weeks
ago,
with
the
developer
from
datadog.
This
is
what
we've
been
talking
about
when
we
released
the
official
tracing
API
like
what
is
that
versioning
compatibility?
B
A
E
Concern
is
transitive
dependencies,
though
right
you
have
data
dependency,
which
has
some
dependency
on
API
V2
and
you
haven't
updated.
Your
SDK
I
still
think
it's
best
to
fail
fast
at
compilation
time
there,
because
you're
going
to
learn
that
either
before
you
even
make
a
PR
updating
your
dependency
or
you
know,
you're
say
it's
dependent
about
that.
That
PR
is
then
going
to
fail.
Your
tests
and
you're
going
to
have
a
very
quick
indication.
Okay,
I
need
to
do
something.
E
B
But
that
doesn't
Okay
so
sure,
but
then
you
have
to
release
that.
So
that's
release
number
two
right.
So
it's
the
same
thing
like
yeah
I
can
release.
You
know
supports
the
V1
API,
then
version
1.1
supports
the
V2,
but
like
I
can
do
1.1
with
another
embedded.
No
op
from
V2
or
I
can
just
fix
the
to
support
V2.
So.
D
E
D
Here
I,
let
me
see
if
I
can
pull
up
the.
B
But
it
wouldn't
actually
be
a
V2,
so
does
the
import
path
still
doesn't
change,
so
you're
still
actually
still
relied
on
the
V1
you
can.
You
can
tag
it
as
a
V2,
but
it
still
relied
on
the
API
from
V1.
The
no
opt
from
API
V1
just
doing
an
upgrade
in
the
go.
Mod
is
not
going
to
change
that.
D
So
I
I
think
we're
talking
about
two
slightly
different
scenarios.
In
one
we
add
the
no
op
to
we
embed
the
Noah
and
we
add
the
function
in
a
minor
version,
though,
and
then
there's
a
different
case
for
if
we're
taking,
if
we
have
a
major
version,
so
in
the
case
of
the
minor
version
bump,
if
the
no
op
is
embedded,
then,
when
you
take
that
when
you
take
that
new
dependency.
B
B
D
D
Like
can't
it,
if
the
view,
if
you
have
a
V1
SDK,
if
you've
only
pulled
in
the
V1
SDK
and
you're,
only
using
the
V1
API,
like
you're,
only
registering
the
V1
API
in
your
application
code,
because
you
haven't
updated
to
V2
API
like
your
dependencies
have.
But
you
haven't
then
you're
not
going
to
register
the
V2
API,
the
V2
Tracer
provider.
E
E
B
Yeah
and
then
yeah
exactly
but
I
mean
like
back
to
your
original
point,
though,
like
there's
there's,
it
doesn't
solve
the
issue.
If
we
embed
it
V1
no
op
right,
no
because
like
like,
if
we,
if
we
do,
that
in
a
release
of
an
SDK
that
supports
the
V1,
everything
works
right
and
then
the
instrumentation
upgrades
to
V2.
B
D
E
B
B
E
B
E
B
B
B
A
B
E
B
D
A
D
If
we
are
going,
if
the
path
forward
is
to
implement
major
changes
with
V2s
and
that
that's
kind
of
a
big,
if
then
I
don't
think
we
need
the
no
op.
A
B
No,
this
is
good.
I
think
this
is
really
good.
I'm
gonna
write
this
down
to
the
docs
I
I.
Think
then
so
so
what
I'm
hearing
is
I
want
to
I
want
to
revert
the
no
op
PR
I
want
to
make
an
RC
and
then
over
the
next
two
weeks.
B
Oh,
my
gosh,
it
I
feel
like
we
did
this
exact
same
thing
in
the
tracing
stable
release,
where
we
were
just
like
I,
don't
even
know
what
we're
doing
at
the
end.
Okay,.
D
D
B
Thank
you.
Yes,
would
you
like
to
take
the
action
item
on
that.
D
Let
me
let
me
double
check
my
schedule.
I
know,
I
know
I'm
mostly
clear,
but
mostly
clear,
isn't
necessarily.
D
B
This
is
recorded
so
I'm
gonna,
say
Google
Concept
for
how
to
evolve
the
global
API
with
a
V2
Pro
inviter.
B
We
need
a
proof.
This
could
be
the
same
PR
or
whatever
Concepts
on
how
to
evolve.
Instrumentation,
provide
or
options
does
that
make
sense,
Anthony
and
Aaron
what
that
means.
Let
me
double.
D
Check
the
stock
okay
with.
E
E
I'm
not
even
sure,
it's
possible.
That's
why
I
asked
okay.
B
Okay,
I
don't
plan
on
sharing
this
too
much
but
yeah.
If
you
can
figure
out
something
yeah.
D
I
I
will
I
will
do
my
best.
Just
a
heads
up,
I
will
not
be
I
will
be
on
a
plane.
Next
Thursday
unexpectedly.
B
Oh
okay,
during
this
meeting
as
well.
B
Yeah,
okay:
I
should
be
there;
okay,
that's
not
too
easy,
yeah
I,
so
I'm
happy
to
pick
up
whatever
needs
to
be
done
here,
because
I
like
this
is
like
having
the
RC
is
my
top
priority,
so
I'm
happy
to
help
Aaron.
If
you're
not
able
to
jump
in
here,
just
just
ping
me
and
so
I.
D
Will
start
on
a
I'll
start
on
it
today
and
work
on
it
through
tomorrow,
and
then
I
will
try
and
get
some
kind
of
at
least
a
plan
of
where
we
can
go
and
what
how
we
would
actually
test
it.
Okay,
because
I
think
there
are
a
lot
of
different
edge
cases,
that
we
need
to
make
sure
that
we
at
least
talk
about
not
necessarily
have
a
solution
for
it,
but
have
a
password
on.
B
I
agree,
so
do
you
think
you
get
out
of
an
issue
created
for
tomorrow's
Sig
meeting
or
do
you
think
a
PR
yeah
I.
D
B
I
think
that
sounds
fair
I'm
gonna
see
see
what
that
looks
like
yeah
and
then
maybe
also
like
have
an
example,
instrumentation
library
or
something
that
upgrades
to
it.
Yeah.
B
Okay,
that
sounds
good
I'm
going
to
submit
a
PR
I've
got
a
a
hungry
dog
that
needs
to
get
fed,
but
other
than
that
I'm
going
to
send
a
PR
for
the
knob
and
then
I
hope
I
can
get
an
RC
staged
if
not
released
before
tomorrow's
Sig
meeting
is
the
goal.
E
A
B
Okay,
all
right,
that's
good
to
know
for
next
time.
That's
perfect!
Okay,
awesome,
all
right
cool
thanks!
Everyone
for
meeting
that
was
extremely
beneficial
and
I
think
moved
things
along
faster
than
I
thought
we
would
okay,
yeah
I,
know
or
tomorrow
thanks
anyway,.