►
From YouTube: GraphQL.js Working Group - 2022-09-28
Description
GraphQL is a query language for APIs and a runtime for fulfilling those queries with your existing data. GraphQL provides a complete and understandable description of the data in your API, gives clients the power to ask for exactly what they need and nothing more, makes it easier to evolve APIs over time, and enables powerful developer tools. Get Started Here: https://graphql.org/
A
A
A
Yeah
so
let's
start
yeah
going
for
agenda
if
you're
watching
the
recording
and
want
to
join
this
meeting
to
discuss
a
graphics
topic,
you
need
to
sign
specification,
membership
agreement,
participation,
guideline
and
code
of
conduct.
All
the
links
are
in
agenda
yeah,
like
introduction
of
appendices,
only
two
of
us,
it's
written,
but
it's
human
agenda,
so
hi
my
name.
Everyone.
A
Yeah,
we
have
one
agenda
item
unless
rob
you
want
to
have
something
else.
By
the
way,
do
you
want
to
discuss
something
else
or
it's
like
about
execute
and
experimental,
execute
each
one
to
discuss,
but
yeah.
B
I
wanted
to
to
discuss
with
jagov's
item
about
incremental
delivery.
A
At
some
point,
yeah
I
think
like
some
of
them
like
resolve
itself
like
vegetarianism
much
stream,
24
I
release
Alpha
two
but
I'm,
not
sure
yeah
I
didn't
pin
you,
but
maybe
you
saw
a
release,
Alpha
2,
which
includes
stream
before
us.
There
is
still
problem
with
GSM
unexpectedly
I
thought
I
will
much
whisper
from
from
the
guilt
and
it
will
work
but
yeah.
There
is
like
some
things
about
this.
Some
I
need
to
fix
so.
A
No,
no
opposite
so
previously,
by
the
way
we
have
time
to
discuss
stuff
since
we're
still
waiting
for
Yahoo.
So
one
story
short
previously,
we
had
like
suggests
traffic
address
for
CJs
package,
but
it
can
some
MGS
files,
but
it
didn't
work
with
not
properly
so
like
I
wanted
to
try
to
go
like
radical
and
nobody
opposed
it.
So
I
just
switch
to
MGS.
A
We
discussed
it
right
half
a
year
ago
when
I
switched
to
MGs
fully,
but
if
there
is
like
feedback
from
The
Guild,
Warren
I
think
open,
open
an
issue
and
I
also
get
the
feedback
from
from
David
saying
the
same.
It's
like
ecosystem
is
not
ready,
so
idea.
I
found
like
this
old
piano.
We
discussed
like
this
alternative
solution
because
it
is
a
simple
alternative
solution.
I
could
find
basically
to
release
like
two
packages,
one
she's
less
than
one
enters
I'm,
not
it
and
it's
kind
of
work,
but
like
I.
A
And
just
part
need
to
be
so
like
Alpha
2
contain
it's
like
fully
suggest
package,
it's
very
similar
to
version
16..
So
content
is
the
same.
It's
basically
version
16,
with
everything
on
the
master
on
the
main
and
esm
version
should
should
have
the
same
code.
But
as
esm,
one
issue
is
so
I
created
how
how
semantic
versions
work
in
the
original
proposal.
It
was
agent,
dashism,
2,
2
version,
and
it
doesn't
work
because
it's
been
writing
perfect.
A
It's
pretty
release
I,
try
to
be
clever
and
use
plus
sign
and
because
same
version
now
we
will
assigned
until
I
I
write
had
an
issue
that
and
Pam
prevents
you
from
publishing
multiple
version
of
the
same
package
and
it's
three
to
like
a
plus
things
after
a
plus
sign
as
non-unique
thing.
So,
basically,
if
you
do
1700,
plus
esm
and
1700
without
the
SM,
you
can
publish
only
one
of
them,
but
I
figure
out
the
solution
basically
like
there
is
npm
support.
Aliases
I
need
to
write
instructions.
A
How
to
use
that
and
idea
is
to
basically
release
packages
and
package
on
the
different
name
so
like,
and
people
can
use
Alias
everything
will
work.
I
check
like
the
differences
working.
Everything
is
like
should
work,
and
basically
it's
like
return
back.
This
idea.
That
suggests
the
main
one.
But
if
people
want
to
experiment,
they
can
use
MGS
and
next
release.
We
can
switch
it
other
way
around
have
like
addresses
the
primary
and
suggests
as
a
secondary.
A
Do
you
see
if
it
I
think
it
will
work?
If
not,
we
can
choose
more
radical
solution,
like
instance
of
and
like
going
through
a
root
of
figure
and
out
like
how
to
use
packages
from
from
different
instances.
So
the
same
package,
which
is
more
complicated,
did
I
did
I
answer
your
question,
or
did
you
want.
A
It
should
look
like
all
the
doors
so
anyway,
yeah
beautiful,
Interruption,
hi,
Jacob
and
I
I
cannot
read
like
Hebrew,
so
I
cannot
treat
the
things
that
I
send
you
to
say
it
in
person
but
happy
Jewish,
New
Year
or
something
have
a
great
New
Year.
A
Yeah
so
we
discussed
basically
I'm
sorry
for
interruption.
A
I
have
a
cat,
so
yeah
and
she
like
I'm
only
one
at
home
right
now,
so
should
try
to
yeah
register
things
yeah.
So.
A
A
It
didn't
work
as
expected,
so
it
needs
some
refinement
and
I
will
I
think
we
have
a
separate
issue
for
that.
So
I
will
write
there,
so
everybody
in
in
in
sync
on
what's
happening
so
I
publish
Alpha
2
and
it's
basically
CJs
only
right
now,
because
I
cannot
publish
second
package
yeah
yeah
get
this
very
active,
so
yeah
we
can
start
with.
The
agenda
item
is
incremental
delivery
and
it's
your
topic
Yakov
so
mic
to
you.
C
Yeah
yeah,
so
basically,
there
are
a
few
PR's
up.
C
I
guess,
I'll,
summarize
briefly,
just
to
make
sure
that
I'm
in
the
right
frame
of
mind
I
think
what
the
what
the
current
state
is
and
and
then
I'll
just
discuss
the
different
PRS
in
terms
of
which
way
we
might
want
to
go
and
in
terms
of
that.
So
basically
we
have
thanks
to.
We
all
know
that
we
have
the
incremental
delivery
has
now
merged
into
into
Maine,
which
is
really
really
exciting.
Really
great
and
right.
Now
we
have.
C
C
But
from
what
I
understand
the
experimental
execute
is
the
is
the
only
way
that
you'll
get
currently
incremental
delivery
enabled,
and
if,
if
you,
if
you
try
to
use
incremental
delivery
directives,
I
either
defer
and
stream
directives
using
execute
that
will
currently
that
will
currently
throw,
but
it
only
throws
when
you
know
like
if
those
incremental
delivery
directives
are,
you
know,
evaluate
to
true
and
and
an
incremental
payload
would
be
returned,
and
so
there
are
a
couple
questions
that
I
have
about
this
in
terms
of
making
sure
that
our
experimental
flag,
generally
speaking
for
incremental
delivery
is,
is
sorry
for
any
increment,
for
any
experimental
capability
is,
is
really
the
way
we
want
it,
and
also
specifically
with
regards
to
defer
and
Stream
So
in
general
in
general.
C
C
The
first
reason
is
that
the
the
the
the
return
type
of
our
functions
actually
changes
based
on
these
incremental
delivery
and
so
from
like
the
typings
perspectives
from
a
types
of
script,
effective,
even
if
you
don't
enable
the
the
functionality
or
potentially
explo
exposed
to
a
new
return
type.
You
know
where
that
functionality
to
be
enabled,
and
so
that's
what
we're
basically
guarding
against
by
having
these
two
different
functions,
execute
an
experimental
execute.
C
We
sort
of
we
sort
of
make
sure
that
that's
not
the
case
that,
if
you're
using
execute,
you
are
guaranteed
to
have
the
original
return
type
of
just
an
execution
promise
of
for
an
actual
execution
result
and
the
other.
The
other
thing
that's
a
little
tricky
with
regards
to
the
incremental
delivery
directives.
Is
that
there's
another
possibility?
Is
that
to
you
to
to
utilize
the
directives
themselves
as
the
flags?
C
You
know
we
were
trying
to
base
as
much
as
possible
in
terms
of
whether
incremental
delivery
is
enabled
on
whether
the
directives
are
actually
in
the
schema
and
and
having
that
just
and
that
just
be
the
only
flag
to
determine
whether
you
have
you
know
incremental
delivery.
Is
enabled
or
not
enabled,
and
now
that
we
have
this
experimental
function
we
sort
of
have
two
different
things
driving
is
it
is
you
know,
and
so
that
leads
us
into
edge
cases?
C
What
happens
if
someone
uses
the
old
execute
function
when
the
the
when
the
when
the
directives
are
in
the
schema
or
what,
if
they
use
the
new
function,
when
the
directives
are
not
in
the
schema
and
in
cases
like
that,
and
so
there
are
a
couple
PR's
up,
my
preference
is
to
make
things
you
know
stick
to
that
Vision
as
much
as
possible.
C
I
mean
the
vision
of
having
just
whether
the
directives
are
in
the
schema
you
know
are,
you
know,
are
driving
whether
you,
whether
you
know
you
really
get
the
new
functionality,
but
but
it's
a
little
bit
it's
a
little
bit
tricky,
and
so
the
the
pr
that
I,
actually
favor
I
guess
is
among
amongst
the
group
is
basically
the
last
one,
that's
three
seven
three
two
and
that
basically
basically
it's
we,
we
basically
don't
at
runtime
we
all
we
only.
C
We
we
enable
a
defer
and
stream.
Basically
if
the
directives
are
are
are
used.
I
mean
the
directives
themselves
are
the
flag
and
those
Direct
don't
really
even
need
to
be
validated
against
within
the
execute
function,
because
they're
assumed
to
be
valid,
meaning
if
they,
if
they're
present
in
the
schema.
We
assume
that
you
know
when
we
when
we
pass
everything
to
execute
we.
C
We
assume
that,
if
they're
being
used
then
defer
and
stream
have
been
enabled,
and
then
the
only
problem
that
we
run
into
is
is
making
sure
that
you
know
there's
still
an
Avenue
for
people
to
have
the
old
return
types
versus
the
new
return
types,
and
we
can
do
that
not
at
runtime.
We
can
do
that
just
using
typescript
conditional
types,
and
so
that
was
my
suggestion
as
to
you
know,
one
way
to
you
know
to
thread
this.
You
know
these.
These
different
concerns
I.
C
C
Another
possible
way
would
be
to
say
that
we
could
have
two
different
functions,
and
you
know
it
could
throw
based
on
the
presence
of
the
directives
in
the
schema
or
not
in
the
schema,
whether
you're
using
the
right
function,
but
I
basically
think
that
there's
a
lot
of
different
options
that
make
sense
and
those
are
in
the
PRS
that
that
I've
set
up
but
I,
don't
think
the
way
we
have
it
currently
is
so
great
because
the
way
we
have
it
currently
is
that
it's,
it
only
is
going
to
give
you
a
warning.
C
If,
if
an
incremental
delivery,
payload
is
returned,
it
happens
to
be
returned,
but
other
than
that
everything
is
going
to
look
great,
even
though
you're
using
like
the
old
execute
function,
and
then
only
if,
like
defer
with
an
argument
of,
if
evaluates
to
true,
then
you
might
get
a
you
might
get
a
problem
and
that
doesn't
seem
to
be
right.
I
mean
it
seems
to
be
that
if
someone's
using
defer
and
stream
you
know
they
get
an
operation
like
that,
it
shouldn't
depend
on
the
response.
It
should
throw
like
immediately
before
execution
starts.
C
So
anyway,
that's
a
little
bit
of
background.
Probably
I
spoke
a
little
bit
too
long
about
it,
but
there's
not
too
much
else
in
the
gender
and
just
throwing
it
out
there
for
synchronous
or
asynchronous
feedback.
B
B
I
I
don't
have
like
a
super
super
strong
opinion
like
I'm
I'm,
fine
with
most
with
I,
think
most
of
these
options,
I
do
want
to
call
out
that
I
I'm
gonna
be
I.
I
had
already
proposed
about
removing
subscription
support,
and
in
that
case,
I
definitely
want
the
behavior
where,
if
you
have
a
defer,
that's
disabled
but
false
the
subscription
should
not
be
an
R.
So
it's
going
to
be
a
a
field
error
only
if
the
defer
is
enabled
I
think
that's
a
different
scenario,
though,
because.
B
It's
it's
actually
not
going
to
be
The.
Proposal
is
not
to
have
subscription
in
the
spec
where
this
is
just
for
what
we
have
here.
I
guess
before
defer
is
finalized,
yeah
I,
guess,
I
guess.
The
question
is
like
where,
where
what
do
we
think
is
like
the
long-term
Direction
after
defer
is,
is
part
of
the
spec?
What
what?
What
do
we
expect?
Graphql
JS
do
so.
Is
this
only
like
in
interim
solution,
or
is
this
yeah.
A
Yeah
basically
think
like
we
still
have
open
questions.
A
I
won't
have
next
to
I
want
to
like
payroll
to
always
have
to
have
has
next
and
if
we
make
it
optional,
like
people
use
important
thing
to
know
about
execution
result
if
I
remember
correctly,
like
people
actually
use
it
on
the
client.
We
have
like
multiple
issues
where
people
use
it
on
the
client
or
as
like
in
middle
verse.
So
it's
not
only
type
useful
as
like
output,
but
for
some
functions
for
some
current
functions.
It's
used
as
input
which
basically
make
like
if
hashmax
previously
was
optional
and
became
normal
optional.
B
A
I'm,
like
until
we
have
like
with
questions
I'm,
not
super
on
like
making
it
non-experimental
and
also
it's
one
point
second
point:
I
think
we
need
to.
We
need
to
have
a
strong
opinion
on
things.
If
we
add
stream
and
G4
we
need
to,
we
need
to
for
not
force
but
rely
right.
If
we
added
in
a
spec
in
first
place,
we
want
all
the
server
to
support
it
right.
A
All
the
protocols
that
can
technically
solve
it
to
support
it
and
I,
don't
see
any
way
problem
with
supporting
it
anywhere.
So
I
think
we
need
to
design.
In
the
long
run,
we
need
to
design
the
API,
as
it
makes
sense
for
Z3
to
extremely
first
first
pass
citizen,
so
I'm
like
I'm
against
Union
of
like
execution
result
or
like
some
structure
with
initial
results
and
subsequent
result,
I'm
just
for
returning
initial
result
and
optional
subsequent
results
subsequent
per
volts.
A
We
discussed
it
with
David
sorry
for
for
changing
like
last
minute,
but
David
wanted
to
use
it
in
the
power
server
and
we
brainstorm
it
and
figure
out
which
structure
like
initial
responses,
subsequent
per
word
and
I.
Think
it's
like
a
Way
Forward,
because
it's
like
eliminate
with
Union
of
types
so
I
might
for
having
maybe
promise
or
from
a
survival
I
forget
how
our
type
is
called
off
object
with
the
neutral
response
or
subsequent
by
what,
which
is
breaking
change
and
I'm
like
and
for
figuring
out
how
to
do
this.
A
Breaking
change
so
I'm,
like
my
my
restriction,
is
like
that
we
should
not
make
mix
like
experimental,
fun
types
and
functions
with
non-experimental,
because
it's
like
it's
a
removable
border
between
what
expert
potential
we
can
break
stuff
by
changing
experimental
things,
and
second
point
is
like
one
ground.
One
term
solution
for
me
is
like
Kevin,
simpler
literature
type
and
having
return
time
optimized
for
like
for
full
use
case
for
streaming
D4.
A
If
you
don't
want
to
use
stream
24
you
just
if
you
use
a
question
of
adding
dot
initial
result
in
your
source
code,
which
is
not
what
we
could
do
and
easier
than
to
have
like
Union
and
try
to
figure
out
what
type
from
a
union
you
actually
got
so
yeah.
It's
my
research
but
I
agree
with
yako
that
current
Way
Forward
is
not.
Is
not
ideal,
it's
confusing.
It's
kind
of
initially
I,
like
I,
spoke
with
David
and
David
actually
made
this
change
for
a
reference.
A
A
Stuff
doesn't
work
that
open
one
potential
problem
you
get
like
errorless
Jacob,
said
potential
problem.
What
if
we
have
seen
good
schema,
served
by
different
protocols
and
protocol
support
or
not,
but
since
entire
ecosystem
treats
stream
DeForest
feature
of
work,
we
discussed
multiple
times
on
the
working
group
and
if
protocol
doesn't
support
stream
and
G4
servers,
should
one
schema
remove
stream
24
and
expose
it
because,
like
it,
makes
sense
for
quantitative
Quant
connects
through
that
protocol,
and
we
agree,
there's
extremely
differs
feature
of
work.
A
It
shouldn't
be
a
situation
where
you
see
extremely
different.
You
cannot
send
stream
extremely
different.
What
and
we
we.
This
is
what
basically
we
have
right
now.
So,
if
you,
if
client
and
like,
if
we
look
at
user
story,
so
we
publish
a
new
version
and
it's
have
like
streaming
different
release,
notes
and
person,
just
put
weight,
add
stream
94
in
his
schema
and
suddenly,
and
he
expects
streaming
before
work
on
the
client,
a
validation
pass.
But
when
he
have
a
strange
error,
saying
streaming
different,
not
supporting
his
way
surprise.
A
Ideally
it
should
happen.
Yeah
so
I
agree
with
yaakov
well
I'm,
like
for
keeping
that
that
idea
in
mind.
A
So
if
you
publish
something,
is
experimental
and
I'm
for
still
keeping
it
experimental
by
the
way,
like
it's
rough
too,
but
time
for
keeping
it
for
for
make
an
official
release
with
it,
but
keeping
it
experimental
people
giving
feedback
and
if
everything
good
with
just
like
Alias
stuff
or
like
figuring
out
how
to
how
to
do
it,
maybe
like
even
do
new
version
specifically
for
that
switch,
but
I'm
for
and
for
publishing
it,
avoiding
people
to
experiment
with
it
and
in
non-confusion
worry
so
I'm
like
for
option
of
of
using
stream
default
direct
us
feature
fog,
but
having
two
functions
and
having
a
bunch
of
time
to
figure
out
return
types
and
getting
feedback
on
it
because,
like,
for
example,
previous
version
with
a
sync
iteratable
with
promise
executioner
without
promise
of
execution
result
or
sync
iterative
of
execution
results.
A
B
I
I
I
agree
and
like
to
clarify
what
I
meant
before
I
I.
Definitely
I
mean
I
I.
B
Think
I
want
to
get
different
stream
in
the
stack
and
I
want
as
many
servers
as
possible
to
support
it
and
I
think
that
we
definitely
should
really
should
iterate
and
have
when,
when
it
is
in
the
stack
have
like
a
good
API
for
how
to
opt
in,
and
probably
the
way
to
opt
out
is,
like
you
said,
not
having
the
directives
in
the
schema
until
then
that
what
I
meant
was
that
until
we
get
to
that
point,
I
don't
know
exactly
how
we
expose
the
experimental
Behavior
behind
a
flag
or
a
separate
function,
or
something
else.
B
And
so
so,
I
I
think
what
you
said
of
in
the
original
function,
checking
the
schema
for
deferred
stream
and
throwing,
if
they're
present,
that
that
makes
sense
to
me.
A
Yeah
I'm,
like
I'm,
actually
I,
haven't
one
argument
that
if
we
all
agree,
it's
provide
us
roadmap,
so
I
want
I.
Think
like
a
Way
Forward
is
to
have
like,
in
your
last
pair,
that
you
send
Yakov
is
52.78
and
I'm.
Looking
at
I'm.
Looking
at
sorry,
my
ghost.
A
Yeah
so
and
I'm
looking
at
right
now.
C
The
last
one
is,
is
three
I
mean
basically
I
mean
I
agree
with
both
you
and
I
guess,
I'm,
just
about
the
long
term
and
I
guess.
I
I
also
don't
have
too
much
preference
as
whether
we
use
experimental
function.
The
other
option,
though,
is
an
experimental
option
and
the
other
option
is
which
was
the
last
one,
that
I
was
kind
of
favoring,
but
again
it's
not
very
strongly,
but
was
basically
not
to
do
any
runtime
checks
and
just
to
allow
typescript
to
infer.
C
You
know
they
basically
like
to
have
an
experimental
option
just
for
typescript.
So
those
are
the
three
options,
meaning
we
could
have
a
runtime
check
and
that
could
be
guarded
by
a
separate
function
or
a
separate
option.
I
just
I,
the
the
one.
The
one
thing
that
I,
don't
think
is
is
the
way
we
have.
We
have
it
now,
but
it's
just
a
small
change
and
we
have
a
lot
of
options
here.
A
Yeah
I
wanted
to
quickly
ask
if
we're
on
the
same
page.
I
have
like
some
technical
problem.
So
now,
if
I
remember
correctly,
yeah
like.
A
A
If
so,
it's
a
breaking
change.
There
is
no
like
way
around
it.
We
can
figure
out
how
it
to
make
it
less
breaking,
but
in
in
one
term
it's
improved
like
the
X,
because
Union
types,
especially
between
objects,
is
angle
in
typescript,
it's
very
hard
to
detect,
which
type
you
get
and
like
is
it's
bad
developer
experience.
So
if
you
all
agree
that
we
want
to
migrate
to
this
object,
type
with
initial
result
and
subsequent
pivot
I
think
it's
a
bad
thing
to
have
like
intermediate
types,
because
it
it
might
migration
harder.
A
It's
not
like
immigrating
from
one
type
to
another
type.
You
you
make
one
types
I'm
like
I'm
for
keeping
it
simple
and
trying
to
switch
from
wet
to
wet
and
keep
like
it
simple
and
your
solution
with
two
functions,
but
initial
check
I
keep
it
like
that.
So
it's
keep
it
like
readable.
It
says
you
to
understand,
and
migration
is
less
confusing.
A
C
Sorry,
yeah
I
think
so
that's
one
of
the
earlier
PR's
I
I,
basically
I,
think
we're
on
the
same
page
so
I'll
just
after
this
meeting,
I'll
close
all
the
other
PRS
and
I'll
put
one
that
I
think
were
with
the
two
functions
and
we'll
we'll
check.
If
I
remember
right,
we're
saying
that
if
you're
using
the
old
execute
function
but
a
schema
has
defer
and
stream,
then
you
should
defer
or
stream.
Then
I
guess
you
should
get
an
error,
but
not
the
other
way
around.
C
You
should
be
able
to
use
the
new
function
with
the
schema
without
and
I'll
close
all
the
other
ones
we'll
have
this
one
I
think
even
one
of
them
is
pretty
close
to
that
already.
So
we're
good
we're
good.
A
Yeah
one
thing
it's
like
from
David,
because
in
Apollo
we
want
to
support
before
without
the
Stream
at
least
initially,
so
those
who
work
in
bad
condition
like
so
function
support
just
before
or
just
stream
or
like
different
stream
of
stuff
without
different
stream
experimental
function.
But
if
you
in
normal,
execute
function,
if
you
pass
a
stream
Etc,
if
you
pass
schema
video
for
this
error,
if
you
pass
schema
with
streamer
and
difference,
also
error,
so.
C
A
A
Because
it's
it's
a
use
case
for
us:
yeah,
yeah,
okay,.
B
So,
basically,
what
we
have
from
what
we
have
now
the
change
is
really
just
changing
the
validation
from
being
like
after
the
afternoon,
everything's
done
checking
if
anything
happened,
versus
checking
the
schema
before
we
start
execution,
I
think
yeah,
that's
what
I
think
and
then
and
then
the
idea
is
from
there.
We
have
this
experimental
execute
function
and
we
should
keep
iterating
on
the
types
until
we
think
that
that's
something
that
could
ultimately
replace
the
original
execute.
A
Not
only
first,
not
only
like
subsequent
jakov
suggests,
like
drop
and
has
next
at
all,
so
we
in
a
stage
of
like
figure
and
out
response,
yeah,
I'm,
Mike
yeah,
and
by
the
way,
how
about
it?
It's
it's
too
quick
like
a
long
time
for
version
17
and
a
lot
of
change
happened
so
I'm,
like
I
reviewed
stuff.
A
A
We
will
figure
out
with
two
two
main
things:
esm
and
nums,
and
have
like
your
change
to
Yakov
change
that
you
propose
to
exit
to
execute
function
and
this
we
release
like
a
release
candidate
like
better
or
better,
probably
better,
ask
people
to
test
it.
Release
candidate
release
it
because,
like
if
we
in
Alpha
stage
not
a
lot
of
people,
we
actually
try
streaming
before,
and
so
we
release
it
version.
A
17,
please
experimental,
execute
function,
allow
people
to
try
and
use
it
in
production
kind
of
production,
but
the
notes
experimental
because
it's
like
function
say
it's
experimental
and
have
version
and
switch
mine
to
version
18
and
work
on
like
having
one
function:
how
to
do
migration,
how
to
do
with
breaking
change
with
the
type
but
having
progress
for
for
half
a
year,
half
a
year
of
progress
released
and
have
a
new
extreme
and
D4
in
the
hands
of
people
to
try
as
experimental
feature
but
unstable
release.
A
Yeah
about
yeah
what
plan
oh
yeah,
I
will
yeah
I
will
open
an
issue
and
like
point
there
like
it
about
MJS
about
numes
and
Europe,
are
about
like
release
checklist
and
see,
like
maybe
people
think
something
else
is
super
critical
before
release
and
we
we
can
start
going
through
through
release
process.
A
Yeah
anything
else
we
want
to
discuss
with
you
have
like
18
minutes.
A
B
A
The
way,
what
what
do
you
think
is
a
best
approach
like
because
me
and
yaakov
suggested
that
a
few
topics,
a
few
like
discussion
points,
do
we
need
to
add
them
separately
or
you
will
do
like
a
batch
discussion,
as
you
did
previously.
B
Yeah
I
was
gonna,
say.
Let
me
know
what
what
topics
you
want
to
discuss
and
I
could
add
them
all
to
the
agenda.
A
A
Over
the
open
topics
make
sense
and
plus
it's
like
extremely
difficult
topic,
important
so
like
I,
don't
think
anybody
will
argue
against,
like
Kevin
like
half
an
hour
of
streaming
before
and
but
but
progress
it
faster.
A
B
A
Yes,
we
will
have
I
think
there
is
like
some
other
topics,
also
from
other
people.
You
did
a
good
job
previously
on
like
going
from
through
them.
So
if
you
do
it
that
time,
you
can
have
a
lot
of
progress
in
single
meeting.