►
From YouTube: 2021-10-21 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).
B
A
C
A
Let
me
share
the
document,
just
one
topic
that
I
had
it
for
today,
that
was
in
the
channel.
A
A
So
let's
see
last
meeting
actions,
I
don't
know
if
there
were
any
yeah
remove
data
level
from
their
project.
Your
semantic
version
that
was
decided.
A
We
talked
about
the
synchronized
clock
with
ntp
code
and
just
review
client
sites
planning.
Okay,
no,
there
were
no
actions
there.
One
thing
I
wanted
to
add
is
that
I
released
yesterday
a
version
of
the
library
because,
with
the
previous
one,
zero
six,
we
broke
compatibility
with
xcode
11
because
of
the
swift
I
don't
know.
What's
the
name
of
that
library.
A
So
what
I
did
was
bring
a
fix
to
the
to
the
package,
so
we
can
use
versions
before
one
with
an
outdated
way
of
selecting
versions
in
the
package,
but
there's
the
only
way
that
it
can
work
and
download
and
compiling
xcode,
11
and
xcode.
A
So
I
released
that
version
with
all
the
small
changes
that
there
were
only
a
bit
of
more
changes,
but
I
thought
that
it
was
important
to
have
to
not
to
break
compatibility
with
something
in
a
fixed
version,
whatever
it
is.
So
I
I
release
that
so
the
the
topic
I
had
for
today
was
exactly
that:
one,
how
we
maybe
it's
not
a
decision
to
take
today,
but
we
should
think
about
what
versions
of
swift
we
want
to
support.
A
A
We
currently
support
from
xcode
11
and
some
a
nice
version,
so
we
are
supporting
many
old
versions
of
ios
and
tv
os
next
code
from
version
11.
That
is,
I
think,
is
the
one
that
supports
ios
11,
for
example.
If
you
want
to
be
back
ios
11
that
we
are
supporting,
you
need
xcode
11,
that's
so
it's
the
at
least
the
11.7,
so
yeah.
A
If
we
move,
if
we
continue
moving,
we
will
have
to
probably
just
disregard
some
old
versions
of
xcode,
swift
or
even
yeah
or
even
macos.
So
currently
we
support
this
5.2.
A
That
means
xcode
11.7.
So
so
we
we
yeah.
I
don't
know
what
kind
of
plan
we
should
follow
from
now
on,
because
we
also
have
to
somehow
add
you
know
new
things
to
the
library.
A
A
But
if
we
change
something
to
this,
maybe
we
should
we.
We
shouldn't
break
anything
either
if
we
follow
semantic
versioning,
but
if
we
want
to
stop
support
xcode
11,
for
example,
if
we
go
to
something
like
this
is
a
very
high
change,
change
right.
A
I
don't
know
if
we
should
just
move
to
the
first
to
the
second
number,
if
we
so
we
want
to
modify
one
of
these,
we
will
have
to
increase
this
number
so
that
people
can
still
fix
to
the
fixed
version.
Next,
I
don't
know
what
do
you
think
about
that.
B
B
It's
like
it's
a
curious.
It's
a
curious
conundrum
because,
like
technically
we're
supporting
the
version
of
ios,
it
can
run
on
maybe
not
the
tools
that
it
uses.
So
so
maybe
we
can
get
away
with
only
revving
the
the
minor
version
rather
than
the
major
version.
What
do
you
think.
B
B
Yeah
no,
I
agree,
I
think,
that's
correct,
but
you're,
proposing
that
we
only
update
the
minor
version
for
these
sorts
of
changes,
and
I
think
I
think
that
I
think
that's
reasonable,
because
we're
not
losing
compatibility
with
the
version
of
ios
we're
supporting
we're
losing
compatibility
with
the
tools
that
that
is
used
to
build
it
right
so
like
if
we,
if
we
were
to
update
our
supported
version
of
ios,
then
that
might
that
that
should
require
a
major
version
bump.
B
I
think,
whereas
this
is
a
minor
version,
we
just
need
to
call
out
that
you
know
we're
just
updating
to
the
to
the
or
we're
just
updating
the
tooling,
and
I
think,
that's
kind
of
in
line
with
apple's
like
design
too,
because
they're
very
willy-nilly
with
their
support
right
like
they're.
Just
like
we
don't
like
backwards
compatibility.
So
you
know
you
better
update.
A
Yeah,
that's
true,
I
mean
probably
you
cannot
run
in
the
new
os
you.
You
won't
be
able
to
run
probably
xcode,
12
or
even
xcode
11
for
sure
you
won't
be
able
to
run
when
they
release
the
new
mac.
Os
version
now
yeah,
but
I
was
thinking
also
about
changing
the
miner
version,
also
for
dropping
some
ios
version
support
because
probably
changing
the
major
I
I
usually
think
more
of
semantic
versioning
for
the
code
of
the
api.
A
So
I
don't
know
if
we
should
keep
that
semantic
version
in
only
for
the
api,
so
the
open,
telemetry
api.
B
Yeah,
that's
a
good
point
too,
like
it
should.
Maybe
it
should
just
be
in
reference
to
when
you're
using
this
yeah,
it's
it.
It's
it's
tough
and,
I
think
yeah.
Maybe
it
might
be
a
good
idea
to
define
this
and
write
it
down
so
that
people
who
are
using
the
the
the
sdk
can
can
understand
it
at
whatever
we
decide.
A
A
Yeah
he
just
asked
for
clarification
about
that
yeah
and-
and
I
think
that
he,
if
he's
gonna,
use
it
in
a
production
environment
as
we
as
I
am
doing,
but
okay,
my
production
is
not
so
I
mean
it's
a
developer
tool
what
I
am
working
on,
so
the
developer
can
be
more
or
less
change
easier
than
a
final
client.
So
you
are
using
that
for
production
for
final
client.
Then
you
probably
need
to
know
that
better.
So
you
can
know
what
to
expect
when
you
update.
B
Yeah
yeah,
I
think
that,
just
because
it's
a
nightmare
to
support
old
versions
and
apple
makes
it
really
difficult
to,
like
you
know,
use
xcode
12
with
xcode
11
and
that
sort
of
thing,
maybe
our
stance
should
just
be
like-
expect
the
the
library
to
update
to
the
latest
tooling
as
soon
as
possible
and
we'll
you
know,
bump
the
the
minor
version
when
we
do
that.
B
A
A
But
the
question,
for
example,
is
that
if
you
have
a
client
or
if
you
have
to
support
ios
11
for
for
an
app
and
your
user
is
using
that
you
know
it.
It's
not
very
use
usual
in
ios.
But
when
you
work
for
a
company
that
builds
apps
for
users
for
final
users,
usually
they
decide
that
you
have
to
maintain
like
compatibility
for
three
or
four
versions
before
the
one
running.
A
A
The
the
problem
is
that
you
need
to
use
xcode
11
for
that,
for
example,
if
you
want
to
debug
an
ec
there,
you
need
xcode
11..
Maybe
you
have
to
have
a
computer
with
another
version
but
of
mac
os
that
supports
running
that.
A
So
you
don't
you,
you
just
have
a
one
machine
dedicated
to
that
or
even
for
other
versions.
You
couldn't
run
xcode
10
now,
for
example,
in
your
current,
so
you,
if
you
are
supporting,
for
example,
ios
9,
you
need
xcode
10
and
you
will
have
to
go
to
an
old
machine
to
run
xcode
10
and
try
to
debug
that
so
that
that's
a
problem
so
yeah.
I
think
we
should
try
to
support
the
the
oldest
version
possible,
but
maybe
we,
if
we
have
a
change
like,
for
example,.
A
We
are
supporting
that
now
for
the
current
for
the
forgetting
the
current
span,
but
because
we
needed
to
do
that,
but
also
would
improve
a
lot
the
api
if
we
could
use
that
kind
of
things,
that's
something
that's
not
going
to
happen
soon,
because
probably
apple
is
still
not
supporting
old
versions,
but
if
they
decide
to
have
an
update
that
works
with
ios
13,
maybe
we
should
just
move
to
having
a
minimum
ios
13,
just
because
everything
will
be
so
nice
to
write
so
yeah.
A
B
Right
right
now
the
sdk
supports
the
minimum
version
of
ios
11
right.
Yes,.
A
And
we
shouldn't
break
that.
I
mean
we
should
at
least
we
have
in
the
current
thing.
We
have
that
we
are
just
fixing
things.
A
Maybe
we
shouldn't
break
that
if
we
have
to
break
that,
I
we
we
should
change
the
number,
because,
if
not,
they
will
update
automatically
to
that
or
something
like
that,
maybe
and
that
will
break
everything.
That's
what
happened
with
the
106
that
just
stopped
working
with
xcode
11.
C
A
A
B
A
Yeah
maybe
appear
yeah,
I
don't
know
if
a
pr,
so
people
cannot
or
just
an
issue
and
ask
people
to.
A
A
Then
I
will,
I
will
open
minshiel.
A
A
A
C
So
is
there
any,
you
know,
guidelines
from
the
spec
on
how
to
do
the
versioning?
Is
it
does
all
the
language
sdks?
Do
they
have
to
follow
lock,
step,
like
you
know,
when
there's
a
change
in
the
api.
A
I
mean
there
is,
I
mean
for
for
the
api
itself.
You
really
need
semantic
versioning.
So
that's
what
the
project
follows.
We
have
added
some
functionality
in
the
patch
version.
A
Because
we
were
not
breaking
anything
but
yeah,
maybe
we
should
have
as
bryce
said
version.
10106
should
have
been
a
minor
version
change,
so
it
should
have
been
probably
one
one
zero
because
of
the
matrix
stuff
with
instagram
but
yeah.
I
I
miss
that
and
yeah.
So
maybe
we
should
have
changed
that,
but
we
have
not
added
any
breaking
change
to
the
api
recently.
So
that's
what.
A
A
A
C
Yeah,
I
don't
know
if
you
guys
saw
the
comment
I
made
on
that
issue.
Do
you
do
you
guys
think
that
underscore
envy
is
misleading
to
new
users?
Oh
yeah,
that's
right.
I.
A
I
think
so:
okay
because
yeah,
maybe
it
was
like
that
when
it
was
implemented
yeah,
so
maybe
that
has
changed
then
after
and
we
didn't
follow
the
spec.
A
A
B
A
So
we
found
a
bar
in
the
environment
variables
that
it
was
not
the
one
that
was
causing
the
problem,
but
yeah
that
was
nice.
When
you
find
a
another
bug,
yes
without
finding
the
one
you
are
really
looking
for.
A
B
A
B
A
C
A
I
don't
know
why
I
would
add
that,
to
the
name
but
yeah,
I
also
yeah.
I
also
created
another
environment,
variable
that
at
the
at
buildkit
decided
to
use
that
also
I
just
I
had
invented
it,
so
they
they
now.
I
think
they
want
to
change
to
something
more
standard,
but
it
was
something
that
didn't
exist.
So
I
took
a
name
and
built
it.
Project
also
decided
to
use
the
same
name.
I
did
so
that
was
quite
fun,
but
yeah.
A
A
A
A
A
A
Yeah
in
environment
context,
propagator,
it's
a
text
map
propagator
that
just
said
using
the
same
format
from
v3
c.
It
just
uses
this
transparent
and
registry
and
puts
it
in
the
environment
variables.
A
C
A
A
Okay,
any
other
topic
for
you,
no,
no,
no!
Okay,
then
I
will
create
the
issue
for
the
project
and,
let's
see
what
people
think
about
versioning
and
numbers.