►
From YouTube: 2022-09-28 meeting
Description
cncf-opentelemetry meeting-2's Personal Meeting Room
A
B
B
So
you
all
see
my
screen.
C
B
Okay,
so
the
main
agenda
is
like
doing
the
next
Beta
release.
We
want
to
do
it
this
week,
hopefully
in
like
in
the
next
day
or
two,
and
there
are
a
few
things
that
need
to
be
done
before
we
do
the
next
release.
B
So
one
is
this
PR
which
Allen
created,
which
drops
support
for
net
standard
targets
for
the
instrumentation
and
all
the
non-core
packages
yeah
like
if
anyone
sees
any
like
issues
with
this
or
like,
if
there
are
any
concerns.
D
D
I
think
somewhere
below
he
did
mention
that
he
will
create
an
issue
with
this
yeah,
so
we
can
merge
it
and
let
alone
do
that
discussion
later.
Okay,
oh
actually.
No.
We
need
to
update
the
change
log
with
the
link
to
the
discussion
so
yeah,
let's
Okay
Alan
is
here
so.
B
C
Oh
yeah
you're,
looking
at
this
PR,
yes
I,
have
a
I
have
a
long
sorry,
I
haven't
shared
it
yet
I've
been
gotten
pulled
into
a
number
of
different
things.
Today,
I've
I've,
written
and
I'm
still
in
the
process
of
writing,
pretty
lengthy
announcement.
That
kind
of
like
goes
into
all
the
stuff
that
I
think
we've
been
discussing
over
the
past
few
months
and
I.
Think
I'd
like
to
publish
this
announcement.
I'm
gonna
I
was
talking
to
Michael
about
this
earlier
today.
I.
C
D
C
A
You
could
Alan
create
a
branch
and
then
PR
into
that
Branch.
So
we
can
all
comment
but
I,
don't
think,
then
you
have
to
worry
about
CI
and
it
doesn't
actually
have
to
ever
get
merged
to
main
you
could
just
delete
the
branch
when
you
post
it.
C
Open
up
another
PR
per
comment:
you
mean.
A
Yeah,
like
you,
could
you
could
pra
into
Maine,
but
that
comes
with
it.
A
lot
of
jumpsuits
probably
don't
care
about,
whereas
if
you
just
create
a
random
Branch,
that's
not
named,
you
know
mean
something
just
call
it
like
announcement.
You
can
create
branches
off
that
PR
into
that
branch
that
won't
have
any
rules,
so
we
can
do
multiple
PR's,
we
can
come.
We
can
do
everything
and
then,
when
we're
done,
you
can
just
blow
it
away.
Okay,
unless
you
want
it
as
part
of
the
main
repo.
D
C
That
said,
I
think
that
this
PR
I
see
you've
approved
it.
I
guess
it's
up
to
you
whether
you
want
to
merge
this
PR
I
think
it's
kind
of
a
bold
move,
though
so.
D
C
The
yes,
no
I
agree
with
that
I
think
I
guess
my
hope
is
that
even
this
is
going
to
be
kind
of
we've.
Never
one
part
of
me
was
like
you
know,
there's
going
to
be
folks
that
maybe
are
still
on
older
versions,
of.net
right.net5.net
3.1
that
can
still
use
the
API
and
SDK.
C
You
know
one
three
one
from
now
on
into
perpetuity
right,
but
the
instrumentation
from
our
project
has
never
been
released
as
stable
and
as
the
semantic
conventions
continue
to
evolve,
like
it's
gonna
I
think
potentially
get
into
this
weird
state
where,
like
three
one
users,
if
they
still
do
exist
right
will
never
have
stable
instrumentation
that
they
can,
even
if
they
are
fine
with
staying
on
like
an
older
version.
They'll
never
have
it.
D
But
I
I
do
think
that
we
should
not
remove
it
from
core,
at
least
for
this
release
the
one
we
plan
to
do
in
the
next
couple
of
months.
We
should
keep
net
standard
from
that
and
as
soon
as
we
are
done
with
that
release,
we
can
remove
so
at
least
that
way.
If
people
are
using
a
stable
package
in
their.net
code
3.1,
they
can
continue
to
do
so
for
a
longer
time
because
we
likely
to
release
in
November
first
weekend.
D
C
Here,
The
Stance
I
was
actually
thinking
about
proposing
in
this
regard,
for
our
core
packages
was
that,
with
a
major
version
bump
so
say,
open,
telemetry.net
2.0,
that
is
when
we
will
drop
.net
standard
and
move
to
a
stance
where
we
only
support
current
supported
framework
implementation,
implementations
and
then
I
was
thinking
like
going
forward.
C
Given
that
we
are
so
tied
to
system.diagnostics.diagnostic
source,
our
life
cycle
should
effectively
be
tied
directly
to
that.
So
as
say.net
6
comes
to
end
of
life
in
November
2024.,
that's
kind
of
maybe
our
first
opportunity
to
bump
the
major
version
of
open
telemetry.net
to
2.0
to
drop.net6
at
that
point
in
time
and
any.net
standard
targets.
D
C
C
D
C
C
C
I
think
that
I
mean
I'm
I'm,
open
I,
mean
I'm
just
putting
out
a
proposal
I'm
open
to
removing
that
standard
earlier,
but
I,
given
that
it's
a
source,
breaking
change,
you
know
technically
I
think
it's
a
little
yeah
yeah
arguable
like
I
think
that
Andrew
Locke
his
his
article
actually
posted
some
examples
of
libraries
that
have
dropped
versions
and
whether
they
dropped
those
versions
at
minor.
He
has
examples
of
of
libraries
that
dropped
it
during
minor
versions
versus
major
versions,
and
at
least
his
opinion
seemed
to
be
that
technically.
C
This
should
really
be
done
in
a
major
version
and
I
kind
of
agree
with
that
stance.
I
see,
but
he
has
plenty
of
examples
where
there
have
been.
You
know
some
pretty
big
name:
libraries
that
have
drop
support
for
Frameworks,
with
simply
a
minor
version
bump.
So
it's
up.
D
To
us
so
I
think,
if
you're
not
planning
to
do
it
for
the
number
release,
we
have
plenty
of
time
to
come
back
to
it
because
then
we'll
see,
if.net
Team
can
make
a
more
formal
statement
in
there
let's
standard
document,
so
we
can
use
that
as
an
excuse
to
decide
what
whatever
is
our
action,
but
if
you're
doing
it
after
the
1.4,
then
we
can
come
back
to
this
like
three
months
from
now.
C
A
C
D
I'm
going
to
join
so
if
we
have
the
opportunity
we'll
pull
you
also
in
or
we
can
do
the
other
round,
like
basically
asking.net
people
to
show
in
our
community
meeting.
But
let's
do
the
initial
meeting
we
plan
to
meet
them
tomorrow
and
then
come
back
okay.
D
That
sounds
good
yeah,
but
I
generally
agree
with
this
direction
like
if
we
have
like
more
pain
than
benefit
by
supporting
the
Legacy
ones
or
not
legacy
the
next
candidates
that
we
should
try
to
do
it
before
they
become
stable.
So
I
totally
agree
with
the
pr
where
we
are
doing
it
for
non-core.
I
I
would
just
ask
to
delay
it
for
DOT,
the
core
component,
at
least
until
the
1.4
stable,
is
released,
because
that
would
be
the
first
package
which
has
full
metric
support.
D
D
Yeah
so
I
was
discussing
about
like
releasing
so
I'll
have
to
leave
right
now,
but
I
think
like
I
take
Allen,
you
had
some
proposals
about
releasing
I
think
like
between
your
crush
and
you.
You
can
decide
which
one
and
I
will
help
with
the
actual
release,
along
with,
like
maybe
tomorrow,
to
do
the
next
round
of
releases.
B
D
Yeah,
the
only
thing
which
the
main
thing
is
top
down
counter.
We
really
want
that
out,
so
we
can
start
people
testing
it
out.
I
mean
max.
If
you
are
able
to
merge
pay
tomorrow,
we
can
take
it
otherwise,
we'll
make
it
part
of
the
release
like
whatever
is
the
next
one.
We
should
plan
to
do
it
more
often
from
now
till
November,
because
we
will
be
like
very
close
to
stable,
so
having
more
releases
would
help
us
get
feedback
earlier.
A
I
just
want
to
talk
real
quick
about
the
log
stuff
and
yeah.
Yes,
so
Alan
and
I
have
been
working
on
this
a
ton.
We
think
generally,
that
PR
is
good.
There's
still
a
lot
of
open
questions.
How
would
you
feel,
instead
of
me,
trying
to
revert
and
go
back?
I
just
made
everything
internal
on
the
new
one
and
we
just
merged
it
in
so
it's
basically
there
but
inaccessible.
D
A
D
That
would
be
fine
by
me
as
well.
Is
there
any
reason
I
mean
you're
planning
to
get
feedback
from
the
city
log
right,
so
would
you
be
blocked
if
you
are
not
able
to
release
the
city
log
stuff
from
getting
feedback.
C
Michael,
does
that
mean
that
the
newer
apis,
the
landed
for
the
extensions
you
you'd
revert
those
as
part
of
this
PR,
the
public
ones,
the
ones
that
you'd
worked
on
over
the
past
few
weeks?
Yes,
basically.
A
The
API
service
that
will
exist
in
Maine
will
be
whatever
was
there
in
130131,
so
all
the
new
extensions,
all
the
new
blogger
provider,
the
new
SDK
dot,
create
log
or
provider
I'm,
just
going
to
internalize
everything
and
I'll,
probably
some
of
the
obsolete
stuff.
I'll
just
comment
out,
so
people
won't
get
obsolete
notices
with
no
New
Age,
okay,
I'll
make
sure
they're
happy
everything
goes
away,
and
then
we
can
put
it
back
in
the
next
release
or
whatever
so.
D
I
learned
the
other
thing:
the
configuration
thing
directly,
the
da
based
config
that
would
stay
in
1.4
stable
that
you
are
not
providing
right.
C
D
Okay,
so
the
only
thing
this
will
keep
internal
is
the
logging
spec
related
stuff
or
logging
SDK,
like
log
emitter
provider,
all
those
things
the
rest
of
the
changes
for
better
PC
configuration
with
di
that
would
stay
and
be
intend
to
ship
that
as
public
in
1.4,
correct,
okay,
makes
sense.
D
B
Okay,
Alan
I
was
actually
I
looked
at
those
two
PRS
that
you
had
created
for
the
new
release,
workflow
update,
so
I
was
thinking.
If
we
were
to
release
the
serilog
package
and
the
log
emitter
package,
then
we
would
need
different
tags
for
them.
So
the
the
newer
PR
which
you
had
created
had
where
we
trigger
the
workflow
when
we
create
a
release
off
of
the
tag,
I
think
do
you
think
it
would
be.
B
B
So
I
was
thinking.
This
would
just
work,
because
this
is
a
very
simple
fix
to
what
we
currently
do
right
like
because
this
is
still
manual
like
we
come
here
and
tell
which
tag
to
run
the
workflow
off
of.
C
Yeah
that
works
so
yeah.
B
C
The
open,
Telemetry
go
project
I
think
is
a
is
a
relatively
good
example
of
what
what
that
option
might
look
like
the
option
where
we,
you
know,
don't
add
that
parameter
where
you
have
to
fill
it
in
and
you
just
they
do
this.
If
you
go
to
their
releases
over
there
and
they
got
it
says
52
releases
over
there
on
the
right
hand,
side,
yes,
I
think
I'm
gonna
be
able
to
find
it.
C
C
A
A
C
If
you
expand
the
branches
up
above
in
that
gray
bar
towards
the
top,
it
says
v110,
blah
blah
and
there's
a
little
dot
dot
dot.
Next
to
it,
you
know,
you'll
see
that
this
hash
actually
has
a
ton
of
tags
that
are
associated
with
it.
So
again,
this
is
just
my
like
kind
of
I.
C
Think
it's
more
just
like
a
perception,
rather
than
like
a
like
a
technical
thing,
but
I
was
thinking
that,
like
basically
when
you,
when
you
go
in
and
you
create
a
release,
it
doesn't
really
matter
which
which
tag
you
choose,
whether
it's
the
serial
log
tag
or
the
core
tag
or
the
you
know
the
RC
tag
or
whatever.
It's
really
that
hash.
That.
A
B
Okay,
so
you're
saying
like
if
we
have
all
of
these
three
tags,
which
is
the
tag
for
gold
components,
for
non-core
components
and
for
the
cellular
log
components,
they're
all
pointing
to
the
same,
commit
same
hash.
Then
this
should
just
work
like
this
one.
B
C
So
that's
another
option.
Basically,
there's
one
GitHub
release
entry
that
just
kind
of
highlights
all
the
all
the
things
that
happened
across
both
core
and
non-core
packages.
D
C
B
C
B
Okay,
yeah
I
was
just
looking
at
the
Garden
three
or
five
doing
things,
so
we
would
just
combine
all
of
these
changelog
entries
into
one.
So
if
this
was
let's
say,
1.3.1
Slash
RC
9.6,
we
would
have
two
sections
one
for
the
one
row
three
one
and
then
for
the
nine
six.
C
C
You
know
that's
at
least
how
I,
because
like
working
at
New
Relic
like
I
I
fiddle
with,
like
almost
all
of
the
language
sdks,
because
we
have
like
an
examples,
repository
and
I
I
I
update
like
our
example
for
go
and
Python,
and
all
these
other
languages,
and
so
I
subscribe
to
the
releases
of
all
those
just
so
that
I
know
when
I
need
to
go
and
like
update
an
example
and
it's
kind
of
nice
to
just
be
able
to
consume
those
those
notes
all
in
one
spot.
B
B
We
could
go
with
this
approach,
then
I
I
I
have
no
issues.
I
think
we
can
update
the
releasing
document
later
with
the
viewer
steps,
but.
B
Okay-
and
this
will
publisher
to
my
get
and
then
okay,
everything
else
is.
A
B
C
C
B
C
B
Yeah
I
think
I'm,
like
I,
can,
like
I,
feel
like
I.
Don't
really
have
to
try
this
one
looks
good
enough.
I
mean
we
can
I
can
try
the
next
release
with
this
approach.
3638.
C
A
C
Benefits
but,
like
I,
think
the
the
main
thing
that
this
solves
is
right
is
what
now
we
can
release
off
of
a
effectively
a
specific
hash,
rather
than
always
off
of
Maine
right,
we'll
never
have
we'll
never
run
into
that
situation.
Again,
where,
like
you
have
like
you,
push
another
commit
to
Maine
and
you're,
like
oh
I,
made
a
small
change
to
like
a
change
log,
and
now
I've
got
like
a
DOT
one.
At
the
end
of
my
my
version
number,
like
that's,
that's
not
possible
in
this
flow
anymore,.
B
D
B
Yeah
and
so
again
sorry
Michael,
like
you,
would
be
sending
those
changes
to
mark
all
those
log
related
types
internal
like
we
expect.
Are
we
expecting
that
before
the
release,
or
do
we
like
do
we
want?
We
want
to
do
that
before
the
release
right.
A
A
B
The
histogram
min
max
PR
I
think
I
have
I
had
done
some
review
earlier
like
two
weeks
ago
or
something-
and
the
comments
are
now
addressed.
I'll
do
a
review
again,
but
yeah
I
mean
we
can
do
another
beat
at
least
next
week,
as
he
just
said,
so
that
could
include
that
one
I
think
it's
getting
a
getting
some
attention
from
people
like,
like
I,
think
of
multiple
people
have
asked
like.
If
this
can
be
most
or
like,
when
will
it
be
available
and
stuff.
B
So
yeah,
that's
all
the
agenda
that
we
have
there's
another
thing
we
wanted
to
discuss
so
in
the
contract,
repo.
B
We
have
some
packages
that
are
still
targeting
net
four
five,
two
and
I
think
last
week,
Michael
was
working
on
releasing
a
package,
and
then
we
had
to
update
the
build
workflow
to
not
run
for
net
452
at
461
as
well.
B
I
think
so
one
thing
we
wanted
to
discuss
was
like:
do
we
want
to
have
our
own
like
support,
Matrix
or
like
something
like
where
we
we
tell
people
to
do
like
you
know,
maybe
kind
of
enforce
people
to
move
to
a
certain
number
certain
version
of
hotel,
at
least
and
not
like
stay
stuck
with
1.1.0
or
something
because
in
contrary
people,
a
lot
of
packages.
They
are
targeting
1.1.0
and
then,
and
they
don't
want
to
go.
They
don't
want
to
upgrade.
B
So
like
do
we
want
to
support
every
package
that
we
every
stable
package
that
we
release
forever
or.
A
The
main
challenge
I
can
trip,
is
you
have
some
packages
like
AWS,
which
I
think
targets
like
four
five,
two
yeah,
so
on
some
poll
requests?
There
was
a
comment
like
hey:
should
we
update
this
to
462
and
whoever
the
owner
is
of
AWS
was
like
no,
we
just
prefer
to
Target
these
old
Frameworks,
so
we
don't
really
have
a
defined
policy
to
say
like
oh,
you
can't
do
that.
So
we
were
talking
about
is
like
we
should
publish
a
policy
that
says
like.
A
A
It's
less
maintenance
for
the
maintainers
if
we
kind
of
nudge
people
to
newer
releases
right,
that's
kind
of
the
theory,
so
the
idea
we
were
talking
about
was
just
to
publish
something
so
that
we
can
use
that
to
say,
like
hey,
AWS
needs
to
be
kicked
forward.
It's
out
of
the
policy,
something
like
that.
Does
that
kind
of
make
sense.
C
C
B
Right
now,
I
we
don't
run
any
CI
49452,
so
the
code
is
only
getting
compiled
for
the
like
I
think
they
have
I,
don't
know
what
their
test
project
runs
on
but
like
what
our
framework
it's
targeting
but
yeah
like
we
have
the
CI
checks
only
for
net462
and
five
and
six
so
and
I
think
this
is
another
one.
But
let
me
take
a
look
at
any
of
the
open
pull
requests.
B
C
So
in
that
respect
like
if
there's
no
CI
that
covers
the
452
Target
of
this
package,
yeah
they've
basically
decided
that's
not
important.
In.
D
C
C
A
I'm
definitely
not
saying
that,
like
so
there's,
there's
an
AWS
package
out
there
with
a
452
Target
people
are
on
it,
they're
happy
I,
don't
think
we
should
like
deprecate
those
packages
or
anything
like
that.
I
just
think
that
if,
if
a
new
one
is
going
to
be
released,
it
should
Target
supported
runtimes.
If
that
makes
sense,
mm-hmm.
A
So
look
at
that
common
area
right
there,
so
that
was
sort
of
my
solution
is
instead
of
having
people
pick
what
they're
going
to
Target
just
use
the
repo,
you
know
definition
and
then
somebody
can
come
in
reap
a
line
and
say:
okay,
now
it's
going
to
be
four
seven
or
whatever
the
heck.
It
happens
to
be.
C
The
tricky
part
with
that
is
that,
if
they've,
if
they
have
pretty
like
pre-compiler
directives,
all
over
their
code,
you
know
with
say
net452
it's
more
than
just
a
simple
like
flipping
that
minimum
supported
framework,
you
actually
have
to
go.
Look
at
the
code
and
see
see
what
else
needs
to
be
adjusted.
C
Yeah
and
as
as
I've
been
going
through
this
like
deprecation
stuff,
really
I
mean
in
this
world,
where
we
have
like,
at
least
in
you,
know
the
main
repository
where
we
have
basically
net
six
and
net
462
I've
found
that,
like
I,
think
almost
all
of
the
situations
now
can
just
boil
down
to
a
simple
like
if
NET
Framework
or,
if
not
NET,
Framework
kind
of
thing,
I
think
there's
very
very
few
examples
for
the
preview
the
directive
needs
to
be.
You
know
one
of
those
or
greater
than
kinds.
B
B
B
I
mean
I
see
their
point
because
they're
they
are
not
the
ones
who
want
to
be
forcing
the
update,
so
I
think
that's
what
the
one
of
the
component
owners
responded.
When
we
asked,
if
you
can
I
had
asked
I
think
that
was
AWS
Lambda
and
asked
like.
Do
you
want
to
switch
to
the
newer
version?
They
said?
No,
we
don't.
We
don't
use
any
of
the
features
of
the
new
rsdk.
B
B
B
A
B
A
D
B
C
C
I
guess
that's
nice,
because
end
users
can
still
use
open,
Telemetry
110..
The
thing
is
that
if
an
end
user
goes
and
then
grabs
say
open,
Telemetry,
one
three
one
by
themselves,
then
that
means
that
absolutely
they're
not
on
net
452
anymore,
like
they,
because
one
three
one
right
that
was
that
supports
462
and
above
right,
foreign.
C
So
the
fact
that
there's
a
net
452
Target
is
kind
of.
Besides
the
point
for
this
package
for
that
user,
targeting
open,
Telemetry
one
three
one,
so
I
guess
I'm
kind
of
I'm
thinking
this
through
myself,
while
kind
of
saying
things
I,
don't
know
if
I
have
a
point
yet,
but
I
think
I
I
think
where
I'm
going
with
this
is.
C
You
asked
AWS,
hey,
you
know,
can
we
update
this
to
one
three
one
and
they
were
like?
No,
we
don't
want
to
be
that
I
mean
in
some
sense
it's
like.
Well,
it
doesn't
matter
AWS
like
the
fact
is.
If
we
upgrade
this
to
one
three
one
and
Target
NET
Framework,
you
know
net
462,
that's
gonna
comport
with
anybody.
That's
upgrading
to
the
latest
version
of
the
AWS
x-ray
package,
anyways.
B
C
C
B
A
C
But
again,
I
guess
it
kind
of
brings
me
back
to
my
thought
that,
like
it's
kind
of
the
code
owners
to
decide
how
they
want
to
service
their
their
stuff,
I
mean
to
me.
It
totally
makes
sense
to
have
maybe
some
like
guidance,
and
maybe
even
some
of
those
helpers
like
Michael
was
showing
with
like
the
things
that
they
can
use.
C
But
maybe
you
know
not
making
it
a
thing
that
we
enforce,
but
just
have
there
as
a
as
a
convenience,
because
I
imagine
that
there
probably
will
be
code
owners
that
are
just
want
to
do
the
easy
thing.
A
Here's
why
I
think
it's
important,
so
there
was
some
security,
vulnerability
and
Owen,
so
I
needed
to
bump
on,
but
I
also
bunked,
that
framework
and
open
telemetry
I
did
open
Telemetry
because
we
know
prior
to
131,
there's
the
reflection
issue.
If
you
happen
to
have
an
older
version
with
a
newer
diagnostic
Source,
you
can
get
into
trouble
if
I
don't
really
want
1.1
out
there,
I
want
people
that
are
moving
to
newer
packages
to
get
you
know
the
safer
version.
A
C
B
B
Had
done,
let
me
sign
in
and
check
quickly.
B
A
B
It
stays
listed
here,
yeah,
so
yeah
anyway,
so
I
know
with
unlisted,
like
you
cannot
search
for
it
and
you
nobody
can.
There
cannot
be
any
newer
downloads
right
if
it's
unlisted.
C
C
B
That's
like
strong
enough
reason
to
make
everyone
move
to
1.3.1,
at
least
because.
B
A
C
Which
but
but
I
mean
out
of
side
like
this
does
kind
of
come
back
to
the
dropping
of
framework
support
I
am
becoming
more
and
more
convinced.
The
dropping
Frameworks
should
be
done
at
Major
version.
Bumps
I
know
that
we've
dropped
them
in
the
past
in
minor
versions,
but
I
I
think
we
should
think
about
that.
A
little
bit
more
deeply.
A
C
B
C
C
Do
we
then
keep
that
Target,
framework.net6
and
then
add.net7
and
then
add.net
8,
9,
10
11
is
like
have
a
bajillion
Frameworks,
but
I
think
the
way
to
just
solve
that
is
to
just
like
tie
open,
telemetries
support
life
cycle
directly
to
that
of.net's
life
cycle
and
just
like
as
dot
net,
makes
major
version
bumps.
We
just
make
version
major
version
bumps
at
the
same
time,
dropping
old
Frameworks,
introducing
the
new
ones
and
I
think
I
think
it
keeps
the
the
the
set
of
Target
Frameworks
that
we
Target
small
yeah.
B
C
A
C
C
Yeah
or
yeah,
maybe
yeah,
maybe
a
system.net
HTTP,
and
then
you
scroll
down
or
you
I
want
to
pull
up
the
list
of
see
I
see
because
because
yeah
starting
with
433
there
was
this.
So
they
just
were
like
yep
anything
below
this,
because
the
security
vulnerability
was
identified
in
433
or
whatever
fixed
in
four
three.
Four
everything
prior
don't
use
it.
B
C
B
A
C
No
necessarily
Owen
is
still
still
a
thing
today.
I
actually
just
saw
a
blog
post
from
David
Fowler.
Recently
I
didn't
look
at
it
very
closely,
but
it
he
I,
guess
there's
this
new
bridge,
this
asp.net
core
bridge
that
helps
existing
Owen
users
more
easily
migrate
to
asp.net
core
or
something.
C
C
But
I
guess
yeah
I
mean
one
interesting
thing:
I
guess
that
we're
observing
here
is
that
there
there
is
a
trend
to
you
know:
choose
the
lowest
common
denominator
until
it,
you
know
no
longer
can
be
done
or
no
no
longer
makes
sense.
I
guess
in
terms
of
like
you
know,
lowest
framework,
lowest
dependency
versions,.