►
From YouTube: Spec 3.0 meeting (March 2, 2022)
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).
C
B
B
The
recordings
are
out
so
you
can
watch
it
on
youtube
and
I
made
a
little
bit
of
a
recap
in
the
end
with
different
timestamps,
in
terms
of
if
you
just
want
to
watch
a
specific
discussion
around
a
specific
subject,
we
are
planning
to
do.
Another
live
discussion
next
monday
same
format.
B
This
time
a
bit
longer,
since
I
was
only
able
to
stream
40
minutes
with
a
private
account.
So
next
time
it
will
be
using
another
one.
We
will
start
at
16
utc
again.
B
E
Nope
but
I
will
be
sure
to
check
out
the
video
thanks
man.
I
was
on
vacation
last
week,
otherwise
I
I
would
have
been
there
and
it
sounds
like
a
great
great
discussion.
B
B
A
Okay,
so
I
just
have
to
check.
I
don't
remember
really.
I
left
some
comments,
but
I
don't
remember
much
from
it.
It
was
before
my
holidays,
but
yeah.
I
I
definitely
will
have
a
look
this
week
and
I
think
we
agreed
already
that
it
has
to
get
in.
A
I
just
yeah,
I
just
don't
remember.
I
remember
that
we
had
this
discussion,
but.
B
B
B
If
we
just
take
a
look
at
the
reference,
for
example,
I
have
given
the
id
of
like
this
remote
url,
instead
of
just
using,
for
example,
reference,
and
this
means
that
yeah
and
it's
because
you
you
can.
But
you
can't
really
use
it,
just
a
name
for
it,
because
the
way
that
the
bundling
of
json
schemas
work
and
that,
in
terms
of
how
references
of
result,
I
wouldn't
be
able
to
have
this
reference
and
then
the
id
being
different.
B
B
B
D
Yeah
I
mean
I
only
propose
this
champions
for
for
dividings
inside
the
dividing
repository
and
jason
schema
yeah
exactly
and
the
binding
spec
is.
This
is
not
the
same
as
essence
api
spec,
so
my
only
concern
about
the
json
schema
where
exactly
we
should
have
in
the
bindings
or
in
the
the
json
spec.
Sorry,
the
spec
json
schemas
repository
is
that
that
people
then
have
to
create
the
two
separate
requests
only
with
very
minor
change
yeah,
so
it
probably
decreased
the
developer.
Experience.
F
Yeah,
that's
the
first
thing
that
came
to
my
mind,
too,
is
that
if
you
change
something
that
means
you
have
to
do
two
pr's
and
two
different
repos
and
you
know
we
tend
to
take
a
long
time
to
approve
prs
so
there'll,
be
this
lag
in
time,
where
they're
out
of
sync
with
each
other.
You
know,
that's
that's
a
concern.
I
have
I'm
just
new
to
this
idea.
I
haven't
read
the
comments
or
anything.
D
Yeah
yeah
exactly
I
propose
to
have
the
json
schema
inside
the
binding
repository
and
then
have
the
workflow
to
copy
that
json
schemas
to
the
another
repository
and
publish
to
the
npm
yeah.
It's
another
way
to
do
that,
but
you
only
make
the
oneplus
request
changing
the
specification
in
the
markdown
then
also
changing
the
the
json
schema
and
the
workflow
down
the
the
rest
of
things
here.
D
D
A
Binding
markdown
files
are
specifications
yeah.
So
so
that's
what
I
only
meant
there
like
it's.
It's
that's
why
I'm
saying
it's
the
same
situation
as
with
jason
schema
for
us
on
dpi
spec,
like
we
split
those
because
json
schemas
are
it's
tool.
It's
not
spec,
while
markdown
file
for
asking
api
and
markdown
files
for
binding
their
specs.
So
that's
why
they
have
to
be
separated.
A
So
when
you
make
a
change
in
json
schema,
you
just
release
a
json
schema.
You
don't
release,
you,
don't
make
every
spec
release
so
yeah
I
mean
contributor
experience.
Is
it's
not
cool,
but
it's
basically
the
same
that
you
anyway
have
to
do
with
the
async
api
spec.
You
have
to
always
make
two
pr's
if
you
affect
the
json
schema,
but
sometimes
it's
just
one
pr
it
really.
It
really
depends.
A
A
What's
the
point
of
the
workflows
you
just
and
especially
that
jonas
now
did
this
tough
job
with
the
with
the
coupling
all
these
references
into
separate
files
to
manage
them
so
plugging
in
binding
schemas
would
be
super
easy
now,
with
json
schemas
or
fasten
api
spec.
B
My
only
concern
might
be
that
we
still
don't
really
know
how
we
want
to
do
the
versioning
of
bindings,
which
is
because
at
the
moment
there
are
no
restrictions
on
whether
you
can
use
one
binding
for
version,
one
or
version
two
of
the
spec
there's
nothing
that
says
that
you
can
can't
share
them,
but
in
a
sense
they
just
it
doesn't
really
make
sense
right,
because
the
bindings
are
kind
of
tuned
to
what
the
spec
doesn't
allow
natively
that
the
protocol
needs.
B
So
so,
even
if
we
move
the
json
schema
files,
would
that
mean
that
like
where
should
they
live
in
the
repository,
because
at
the
moment
we
have
all
the
definition
for
all
the
spec
versions
here
right
should
we
have
a
bindings
folder
that
then
has
versions
for
each
binding
or
and
how
should
we
reference
them
inside
the
j
like
for
the
spec
itself?
How
should
we
reference
the
binding
scheme
as
here?
B
A
If
it's
one
two
three,
whatever
version
of
the
binding,
it's
anyway
like
it's,
it
should
work
with
any
version
right
of
the
spec.
F
The
bindings
are
are
attached
to
like
channels
or
messages
or
whatever
in
it,
and
version
three
of
this
back.
If
we're
going
to
change
the
way
that
we're
dealing
with
channels,
for
example,
that
could
sort
of
make
the
bindings
invalid
right
like
we're
talking
about
reusing
channels,
for
example,
things
like
that.
So.
A
A
A
Yeah,
it
makes
sense,
makes
sense,
but
then
shouldn't
we
just
follow
what
we
have
with
generator
like
when
you
have
a
template,
and
you
say
that
this
template
is
works
with
the
with
all
the
versions
prior.
The
next
major.
F
Yeah
I
mean
I
guess
what
we
could
do
is
when,
as
we
develop
version
three,
we
can
see
whether
any
changes
we
propose
are
gonna
break
the
bindings
or
not
and
deal
with
it.
Then,
where
we
can
plan
ahead
and
give
ourselves
some
flexibility
and
say
well,
let's
assume
that,
like
we
have
the
freedom
to
make
breaking
changes
that
will
break
the
bindings.
F
Therefore,
we'll
have
to
do
something
like
that,
but
but
like
for
example
like
like
the
binding
that
we've
got
for
solace
works
with
version
2
and
version
2.1,
and
you
know
it
says
that
it
works
with
version
two,
because
I
want
it
so
that,
if
somebody's
using
a
parser
version
two
that
they
can
parse
the
binding,
if
they
bump
up
the
say,
bump
up
the
parser
to
2.1,
then
I
don't
want
to
say
well,
you
can't
use
the
solids
binding
version
anymore,
because
it's
sort
of
attached
to
version
two
well,
it
does
work
with
two
one
as
well,
so.
F
I
don't
know,
maybe
I'm
not
sure
how
to
deal
with
that.
Like
at
one
point
you
say
there
is
some
future
version
that
will
break
it.
Like
version
2.1
does
not
break
my
version,
2
binding,
but
version
3
might
break
my
version
2
binding.
B
B
A
I
mean
it
has
to
be
in
the
scope
for
3-0
right,
because,
yes,
we
will
break,
I
mean
we'll
break
like
the
bindings
will
not
work
as
before.
F
Well,
we
don't
know
for
sure
yet
whether
they'll
work
or
whether
they
won't
work.
Yes
exactly
anyway,
I
have
to
switch
meetings.
I'll
see
you
in
a
couple
weeks.
B
A
Would
be
good
only
because
we
have
few
like
so
in
bindings
repo?
The
structure
is
of
the
ownership
is
done
in
the
way
that,
like
you,
have
some
generic
owners,
but
we
also
already
managed
to
identify
some
binding
specific
owners.
So
there
are
a
few
folks
already
that
we
should
definitely
pink
directly
in
the
issue
to
get
their
opinion.
B
A
Just
if
I
can
use
you
if
you're
on
the
call
during
this
two
weeks
when
I
was
out
like
all
this
next
major,
it's
all
configured
already
everything
works.
No
no
help
from
me
is
needed,
like
this
release
pipeline.
If
we
do
something
in
the
parser,
it
goes
to
generator,
etc.
B
I
have
this
down
here.
I
wanted
to
double
check
in
terms
of
what
what
repositories
already
I
did
plan
to
do
it
today,
but
let's
see
okay
and
I'll
make
sure
to
ping
you
if
anything
is
missing.
I
think
friend
created
all
of
them.
If
I'm
not
mistaken,
I'm
not
sure
if
the
repository
itself
is
set
up
to
support
it
like
the
release
pipeline,
but
I'm
going
to
double.
Take
that
as
well.
A
B
B
I
can't
remember
when
we
merge
to
the
next
branch:
do
you
need
to
create
the
first
release
yourself,
like
you
do
when
it's
it's
your
very
first
release
of
a
repository,
or
does
that
happen?
No.
A
No,
that's
that's
automated!
So
well
I
mean
if
it's
configured
then
yeah,
it's
it's
gonna
just
produce
three
zero
zero.
Next
major
whatever
we
are
rc.
A
And
it's
not
going
to
be
released,
it's
gonna
be
pre-released
like
like
with
other
stuff
manually.
You
have
to
create
a
release
only
if
you
do
it
for
the
very
very
first
time,
and
it's
only
because
I
mean
it
would
work
without
manual
release,
but
we
just
don't
like
to
release
majors,
so
we
prefer
to
start
with
zero
zero
one
instead
of
one
zero
zero.
That's
why
we
do
manual.