►
From YouTube: Community Engineering Hangouts 09/15/2021
Description
Agenda:
- Upgrade Compatibility Tool (UCT)
A
Okay,
welcome
on
our
community
engineering
hangouts.
Today
we
have
a
really
really
interesting
good
topic
connected
to
upgrade
compatibility
tool.
We
have
sergey
and
sandra
today
to
cover
all
the
questions
and
interesting
stuff
related
to
this
tool.
So
today,
today,
we
will
try
a
new
format
of
the
event
like
a
live
conversation.
A
A
If
you
want
to
ask
a
question
with
your
voice,
just
to
raise
your
hand,
we
have
icon
with
like
smile
with
the
hand
and
yeah
well,
will
provide
the
ability
to
ask
your
question
and
actually
answer
your
question.
So,
okay,
I
believe
we
can
start
so
upgrade
compatibility
tool.
So
what
is
it?
And
what
is
this
about?.
B
Yeah
so
yeah
thanks
everybody
for
joining
and
as
stanislav,
you
said,
I'm
sandra
gonzalez
and
I'm
the
product
manager
leading
the
upgrade
compatibility
tool,
so
what
the
tool
is
and
what
it's
meant
for.
So
the
the
the
goal
of
the
tool
is
to
help
with
the
upgrade
process.
So
our
intention
with
a
uct
is
actually
to
provide
information
about
what
needs
to
be
done
to
complete
an
upgrade.
B
I
know
we
are
aware
that
a
frontena
might
be
one
of
the
main
issues
when
upgrading
what
we
wanted
to
achieve
with
introducing
first,
these
validations
was
to
is
bring
already
some
value
that
we
could
develop
easily
so
get
something
to
our
users
as
fast
as
we
can
and
something
that
will
also
be
valuable.
That's
why
we
started
with
these
two
validations
php
apis,
because
we
believe
it's.
B
During
the
course
of
this
year
we've
been
working
on
additional
validations,
and
recently
we
launched
the
validations
of
or
the
core
code.
The
idea
is
that
mainly
and-
and
please
stop
me
anytime,
I'm
more
than
happy
as
than
his
life
just
mentioned.
I
think
this.
It
would
be
great
to
have
this
more
conversation.
B
Okay,
okay,
so
yeah,
then
this
year
we
introduced
the
validations
of
the
core.
The
goal
of
this
is
that
we
we
always
our
best
practice,
is
not
to
upgrade
not
to
update
and
to
change
the
the
core,
but
we
know
that
sometimes
it's
it's
difficult
not
to
do
so.
So
the
idea
of
these
validations
is
also
to
take
into
account
all
the
changes
that
have
done
during
a
customization
within
the
the
board
for
next
year.
B
B
We
also
we're
also
taking
into
account
the
two
three
line-
end
of
support
it's
april
next
year.
So
with
this,
we
expect
our
merchants
and
users
and
partners
to
look
forward
to
upgrade
to
two
four
lines
sooner
than
later,
and
the
goal
of
the
upgrade
compatibility
tool
is
actually
to
help
you
with
this
process.
So
the
scope
that
we're
working
with
in
the
next
few
months
is
focus
on
simplifying
this
upgrade
to
four
to
four
line,
and
I
think
I've
said
a
lot
of
things.
B
Related
to
these
validations
that
I
was
talking
about,
and
also
all
the
other
ones
that
we
will
be
adding
in
the
future.
It
will
also
we
have
a
score
that
we
call
the
complexity
score,
that
it
it's
meant
to
give
a
sense
of
how
complex
and
great
can
be
so.
The
way
is
calculated
is
a
based
on
the
severity
of
the
issues
and
the
type
of
issues
that
we
identify.
B
The
idea
how
we
are
recommending
to
use
this
score
right
now
is
use
it
based
for
to
be
able
to
compare
with
other
projects.
So
what
I
mean
is
like,
if
you
run
the
grade
compatibility
tool
on
project
a
and
you
have
a
score
of
a
thousand,
and
then
you
run
it
on
on
another
project
on
project
b
and
your
score
is
2
000.
You
can
assume
that
the
complexity
of
creating
a
project
b
to
the
target
version
is
gonna,
be
higher
than
upgrading
project.
B
B
We're
still
not
there
and
main
reason
is
because
we
don't
have
all
the
validations
that
we
need
to
take
into
account
to
actually
evaluate
the
complexity
of
an
upgrade
in
general,
but
we
do
believe
that
it's,
it's
also
going
to
be
help
a
partners,
mainly
when
you
are
working
on
multiple
projects.
So
you
can
compare
one
product
with
the
other
and
you
can
get
this
experience
on
what
the
upgrade
is
costing
you,
and
what's
this
a
combat
complexity,
score
meaning
within
your
projects.
C
Yeah,
the
complexity
score
is
probably
one
of
the
simplest
and
and
the
same
time,
the
most
complex
feature
of
uct.
The
complex
discord
is
basically
one
of
the
results
that
tool
provides,
and
it
has
a
lot
of
discussion
and
st.
It
had
a
lot
of
discussion,
and
still
there
should
be
lots
of
discussion
about
the
complex
complexity
score
to
adjust
it.
B
I
think
it's
great
just
for
you
to
know.
I
think
I'm
very
happy
that
people
that
joined
is
not
familiar
with
the
tool,
because
that's
kind
of
also
the
idea
of
this
hangout
so
for
you
to
learn
a
little
bit
more
about
it,
and
hopefully
you
will
be
interested
in
using
it
in
in
the
short
future.
So
sorry,
back
to
you.
C
Nice,
nice,
it
works,
it
works.
Thank
you
guys,
good.
So
considering
that
not
too
many
of
you
have
tried
upgrade
compatibility
tool
already.
I
will
just
quickly
show
you
what
it
is
from
the
technical
pointer
yeah
by
the
way,
if
we
haven't
met
before
my
name
is
sergey
and
I'm
currently
leading
upgrade
compatibility
tool
from
the
technical
side.
C
C
Yeah,
I
have
some
console,
let
me
clear
it
so,
basically,
there
is
a
documentation
on
upgrade
compatibility
tool.
Well,
everything
starts
from
documentation
right
with
lots
of
description.
The
most
important
thing
to
begin
with
is
the
installation
documentation
and
that
upgrade
compatibility
tool
is
just
a
magenta
package
that
has
a
simple
name:
magenta
upgrade
compatibility
tool.
C
C
So
one
thing
that
I
have
to
mention
here
installing
magenta
great
compatibility-
it
will
be
a
composer-
requires
adobe
commerce,
assess
keys,
that's
one
important
thing,
so,
let's
take
a
look
on
the
tool
itself,
so
once
you
install
it,
you
will
have,
you
will
have
it
like
here.
I
have
the
project
and
the
simplest
way
to
run
it.
C
Well,
actually,
there
are
lots
of
options
that
can
be
specified,
but
let's
keep
it
simple,
just
the
pass
to
the
project-
and
I
have
some
magento
customized
237
enterprise
edition
project
so
that
we
can
see
actually
some
customization
another.
This
results
and
minus
c
or
a
common
version.
That's
the
option
you
can
specify
to
compare
with
specific
magenta
version.
C
We
can
talk
about
the
errors
specifically
like
their
categorizations
a
bit
later,
let's
jump
straight
to
the
question
that
was
asked
before
and
that
actually
is
present.
In
summary,
so
at
the
end
of
the
execution
we
display
the
summary
you
can
see
that
the
version
237
was
compared
to
the
for
compatibility
to
243..
C
C
So
currently
we
are
still
thinking
on
the
best
formula
on
calculating
the
complexity
score,
but
also,
currently,
the
complexity.
Score
probably
reflects
the
complexity
of
the
upgrade
from
the
back-end
side
side,
mostly
because
the
coverage
of
compatibility
issues
of
ect
right
now
is
focused
on
the
on
the
back
end.
He's
still
still
working
on
this
tool
and
didn't
have
a
chance
to
add
too
many
front-end
coverage.
C
So
that's
the
first
context
of
the
complexity
score
and
for
now
the
formula
is
basically
depending
on
the
number
of
complexity,
issues
that
you
have
on
your
project
and
on
their
severity,
like
the
critical
issue
will
have
higher
weight
towards
complexity.
Score
than
warning,
for
example,
because
warning
warning
indicates
the
deprecated
methods,
for
example.
So
that's
something
that
you
will
need
to
change
in
your
customization,
but
it
can
wait
right
because
it's
still
deprecated
still
not
removed.
C
C
D
D
C
In
case
something
was
changed
or
not,
even
if
something
was
changed
in
the
newer
version,
but
in
case
you're
using
the,
for
example.
This
warning,
let's
that's
an
easy
example,
so
you're
using
the
constant
in
your
code
in
this
file
right
so
in
fake
model
model
fake
deprecated
class.
There
is
a
reference
to
the
config
engine
pass
constant,
so
this
constant
is
deprecated
on
version
243.
C
Well,
for
this
specific
example,
it
can
be
deprecated
on
237
as
well,
so
that
might
be
already
deprecated.
There
is
an
option
to
exclude
excess
errors
that
are
that
are
errors
for
your
current
version
and
you
are
leaving
fine
with
them.
For
example,
just
see
the
errors
that
were
introduced
by
changes
in
243
or
well,
not
in
two
for
three
but
starting
from
two
three
seven
in
all
the
versions
until
the
two
for
three.
C
D
C
C
But
the
packages
of
type
magento
module
will
be
analyzed
and
the
errors
will
be
reported
for
sure.
You
can
also
configure
the
tool
to
analyze.
Only
the
like
specify
the
pass
for
analysis
on
the
to
your
module
that
you
are
working
on
to
avoid
analyzing
all
the
modules
in
the
project.
If
you
would
like
to.
D
C
A
C
E
Hello-
and
I
thank
you,
thank
you
so
much
for
this
presentation.
This
tool
looks
very
interesting
and
promising
from
the
developer
and
business
perspective,
and
I
have
a
question
about
the
main
line:
is
it
possible
to
change
the
main
line
to
which
we
decide
to
compare
our
project
so,
for
example,
some
of
the
branch
which
is
in
development
right
now?
We
want
to
compare
to
our
project
to
have
more
time
to
make
our
project
compatible
with
the
main
line,
which
will
be
released
soon.
C
C
So
once
the
version
is
ready
for
release.
So
our
our
approach
right
now
is
once
the
version
is
ready
to
the
release
and
there
are.
There
is
no
backward
incompatible
changes
supposed
to
happen
anymore.
We
are
going
to
generate
the
new
index
version
and
include
it
so
that
it
can
be
a
bit
earlier
than
the
actual
release,
but
not
too
much
earlier.
So
we
are
trying
to
do
this
just
once
to
allow
all
the
backward
incompatible
changes
that
are
going
to
be
included
in
the
new
version
to
be
present
in
the
index,
but.
B
E
Yes,
thank
you
so
much
sergey
for
your
answer.
Just
because
this
tool,
and
in
combination
with
the
quality
patch
2,
will
bring
to
the
developers
and
to
the
business
a
great
opportunity
to
make
delivery
of
the
new
versions
of
the
magento
platform
more
smoothly
and
efficient,
and
because,
just
if
you
release,
for
example,
244
in
january,
we
will
have
more
time
to
prepare
our
customers.
E
G
Yeah,
actually,
basically,
I
was
thinking
about
like
if
someone
has
added
some
patches
over
or
their
commerce
magento.
So
while
upgrading
it
is
going
to
show
something
like
this
patch
is
not
going
to
be
used
with
the
upgraded
version
or
something
some
notice
about
that
in
the
report.
While
checking
this.
C
C
G
A
A
B
A
Okay,
so
I
don't
see
like
any
any
questions
in
the
chat,
so
I
believe
we
can
move
forward.
So
he
you
showed
us
like
a
small
demo
of
their
tool,
how
it
works,
and
I
saw
that
you
compared
237
with
243
version.
So
is
it
possible
to
compare
like
each
version
between
each
other
or
there
are
some
limitations.
C
Yes,
it's
possible
to
compare
any
version
to
the
version
starting
from
two
three
zero,
like
that's,
that's
a
limitation
that
is
based
basically
on
the
indexes
that
we
are,
including
in
the
package.
We
are
indexing
version
two
three
zero
and
later
so
you
can
analyze
any
version,
but
you
can
analyze
the
upgrade
to
version
230
and
later,
including
all
the
patch
versions
as
well.
A
That's
that's
really
so,
okay,
you
showed
us
also
like
back
back
to
the
demo.
We
saw
some
warnings
there,
some,
like
errors
related
to
some
deprecated
code,
some
duplicated,
constants
and
so
on.
Could
you
describe
like
which
validations
are
included
to
the
tool
and
like
which,
let's
say
feedback
to,
can
provide
about
your
customizations
and
what
you
need
to
do
to
make
them
make
them
work
within
your
newest
version.
C
Yes,
yes,
so
here
I
guess
it's
time
to
return
to
the
report
that
we
had
and
talk
about
and
talk
about,
like
in
more
details
about
theirs
itself.
So,
as
you
can
see,
there
are
three
different
levels
of
errors,
critical
warning
and
error
severity
levels,
and
currently
we
are
very
fine
on
the
the
basically
the
php
code,
the
back-end
side,
using
this
this
command.
There
is
an
additional
graphql
checks
that
can
be
added
via
options
or
we
have
a
dedicated
command
for
that.
C
But
in
this
case
for
now
that's
just
back-end
usage
and
that,
based
on
basically
all
the
codes
of
the
errors
that
you
can
see
here,
all
the
errors
that
you
can
get
you
can
find
the
description
of
the
errors
in
the
documentation
and
then
let
me
jump
and
jump
here.
So
in
the
upgrade
compatibility
tool
section.
There
is
error,
message
reference,
so
it
will
be
easier
to
describe
the
errors
on
this
page.
C
Critical
issues
are
the
issues
well,
first
of
all,
where
the
core,
where
the
magento
is
modified
itself.
So,
for
example,
if
there
are
some
files
missing
in
magenta
core
that
should
be
present
or
if
dependencies
are
different,
like
that,
there
is
different
packages
in
the
core
or
or
even
folders.
I'm
missing
that
that
is
going
to
be
a
critical
issue
for
core
code.
As
for
custom
code,
customization
critical
issues
are
mostly
when
the
entity
that
is
referenced
in
the
code
is
not
present
on
the
new
version.
C
Skipping
graphql
for
now
errors,
error
level
is
are
issues
when
the
customization
code
is
referencing,
any
non-api
entities,
non-api
classes,
constants
interfaces
properties
at
the
the
reason
for
that
is
that
we
are
not
strictly
controlling
the
change
in
the
behavior
of
non-api
classes.
Even
if
the
interface
remained
the
same
for
non-api
class
there
there
is
a
risk
of
changed
behavior
and
also
there
is
some
risk
that
it
will
be
escalated
to
critical
on
the
next
upgrade
as
yeah.
The
the
non-api
changes
are
not
strictly
controlled.
C
Yes,
a
warning
for
core
is
when
there
is
the
all
the
dependencies
in
the
project
that
should
should
be
present
for
the
core
functioning
correctly
present,
but
there
is
some
version
this
much.
Maybe
the
dependency
was
updated
after
the
install
installation
of
magenta
comparing
to
vanilla,
magenta
or
just
the
version
was
changed
because
there
were
there
were
additional
extensions
installed
and
the
composer
calculated
the
versions
in
a
different
way,
all
right
and
and
for
the
customizations
warnings
are
mostly
the
deprecated
different
kind
of
deprecated
entities.
C
C
There
is
another
tricky
warning
here,
so
in
the
critical
section
we
are
identifying
that
the
re
there
may
be.
Maybe
some
calls
to
non-existent
methods
right,
but
we
all
know
that
we
are
using
some
magic
methods
and
there
are
data
data
objects
that
are
identifying
this
map
that
are
introducing
these
methods
to
magenta
customization
slot.
So
if
we
identify
that.
C
C
About
like
the
call
of
non-declared.object
method,
could
that
that
might
be
a
magic
method
or
may
not
like
so
you
in
this
case,
that's
a
warning,
but
you
have
to
pay
attention
to
it
and
ideally
check
it
if
that's
a
valid
magic
method,
but
basically
that's
why?
Because
of
this
kind
of
uncertainty,
it's
always
better
to
use
interface
method
instead
of
non-declared
date.
Object
methods.
A
C
Yeah
we
also
trying
to
provide
some
suggested
actions
here.
They
might
not
be
ideal,
but
I
believe
they
not.
They
may
not
be
as
detailed
for
each
specific
case,
but
I
guess
they
will
evolve,
as
we
will
have
more
experience
in
that
and
if
you,
if
you
are
facing
this
error,
that's
on
the
dev
docs
devdox
is
open
for
suggestions
contributions.
C
C
B
Yeah,
I
think,
just
to
point
on
on
the
feedback.
We
have
our
great
compatibility,
slack
channel
and
I
will
also
share
the
link
now
on
on
this
chat
and
and
we've
been
receiving
great
feedback.
We've
we're
trying
to
work
on
the
improvements
and
suggestions
from
from
that
we
get,
and
mainly
we
get
them
through
this
live
channel.
So
I
I
think,
for
my
side
and
from
30,
we
invite
you
to
to
join
and
share
your
feedback,
your
ideas
to
make
the
tool
even
more
valuable
for
the
future
upgrades.
C
Thanks
for
sharing
sharing
the
link
sandra
yeah,
please
join
the
upgrade
compatibility
tool,
we'll
be
happy
to
talk
with
you
there
like,
for
example,
if
you
will
still
have
questions
after
the
meeting
or
you
would
like
to
discuss
something
more
details.
That's
the
first
place
we
can
meet
and
then
continue
the
conversation
as
there.
B
C
C
C
C
C
Most
of
the
settings
from
the
upgrade
compatibility
tool
are
available
in
this
company
in
in
the
run,
configuration
and
by
the
way,
if
you
don't
have
the
compatibility
tool
installed
you
the
phpstorm
will
will
help
you
to
do
this,
like
displaying
providing
the
ability
to
install
it
right
from
this
dialog.
If
you
will
open
the
run
configurations
right
now
in
your
php
store,
make
sure
the
plugin
is
updated
to
the
latest
version,
because
the
release
was
just
today
and
create
this
upgrade
compatibility
configuration.
C
C
C
You
can
specify
it
as
deep
as
it
like,
analyzing
just
one
module
and
then
you
can
select
the
coming
version
so
to
the
version
you
would
like
to
analyze
the
code
against
two
for
three.
In
this
case,
the
latest
version
you
can
select
any
version
here,
a
minimum
severity
level,
minimum
issue
level.
If
you
are
interested
on
the
fixing,
critical
errors
and
don't
want
to
distract
be
distracted
in
the
report
by
errors
of
warnings
you
can
like
set
the
minimal
level
to
critical
by
default.
C
It's
warning,
so
all
errors
will
be
displayed,
and
this
is
a
setting
that
I
mentioned
previously
like
if,
if
the
extension
is
working
correctly
in
the
current
version,
but
there
are
still
some
compatibility
issues
reported
like
I
don't
know,
using
some
deprecated
classes
and
you're
not
interested
in
fixing
these
specific
issues,
you're
interested
in
fixing.
What's
what
have
changed
since
your
version
to
the
new
version?
C
C
It
also
links
to
the
link
to
the
errors
and
the
description
of
all
the
compatibility
issues
is
available
here.
Just
in
case
you
will
forget
it,
you
don't
need
to
google
to
find
it
and
yeah
so
compatibility
tool
itself
is
exporting
results
to
json,
and
there
is
also
the
result
file
created
from
the
when
you
run
the
html
from
the
run
configuration
of
phpstorm
plugin
can
be
useful
for
let's
say
using
running
it,
comparing
it
with
other
projects
or
other
branches
or
like
just
comparing
it
in
between
sprints.
B
A
C
So,
apart
from
just
providing
the
run
configuration
for
executing
hdcp
from
phpstorm
plugin,
we
decided
to
utilize
even
more
native
functionality
to
the
php
http
storm.
That
is
like
even
closer
to
the
code
to
make
it
even
more
comfortable
for
developers
and
we
have
started
working
on
inspections
yeah.
So
what?
How
do
you
validate
the
code
in
your
project?
You're
using
inspections
right.
C
C
C
Sorry,
that's
a
highlight
in
red
because
that's
a
test
module
for
with
some
errors,
specifically
for
tool
testing,
and
you
can
see
the
error
straight
away
in
the
code.
So
here,
for
example,
we
can
see
that
magento
review
model
review,
summary
class-
that
is
important,
is
deprecated,
but
that's
a
tricky
one,
because
if
we
go
to
the
class
we'll
see
that
it's
not
deprecated
how
how
that
works.
C
So
here
you
can
set
also
the
version
you're
comparing
to
so,
for
example,
like
if
you're
upgrading
to
two
for
three
you
can
set
two
for
three.
If,
if
two
two
four
two
then
on
the
like
classes,
deprecated
into
four
two
2
or
before
242
will
be
displayed
will
be
highlighted,
and
these
are
settings
for
the
running.
C
C
As
you
can
see,
it's
even
executed
faster.
Well,
it
has
less
checks
for
now
and
see
the
results
here.
So
again,
this
review
summary
model.
It
was
deprecated
in
two
for
three
and
if
we
will,
if
we
will
change
the
coming
version,
for
example,
if
you're
going
to
upgrade
to
240
and
run
this
tool,
you
will
see
that
this
error
is
not
repulsive
to
report.
It
anymore
and
review.
Summary
is
not
highlight
right.
So
on
240,
it's
not
deprecated
cool
stuff.
It's
magic!
C
Like
the
same
way
as
as
any
other
inspections
can
be
used,
for
example,
if
you
would
like
to
check
the
module,
you
can
select
the
module
click
inspect
code.
Here
I
have
like
project
default,
with
lots
of
checks
other
than
uct,
like
quad
style
and
so
on.
For
uct.
I
have
created
specific
profile,
uct
that
has
on
the
ucd
checks
just
to
have
only
them
and
running
this
inspect
code
on
the
module.
You
can
see.
Actually,
the
the
issues
in
phpstorm
format.
A
A
Okay,
we
have
three
minutes
left.
I
believe
I
have
a
couple
of
questions
related
to
some,
let's
say
documentation,
stuff
or
like
where
share
the
feedback.
Sandra
already
mentions
that
we
have
slack
channel
for
the
ect
where
you
can
like
share
your
feedback,
ask
your
questions,
and
so
on.
So
is
there
any
any
other
ways
to
communicate
or
if
it's,
the
main
channel
for
use.
B
Yeah,
that
would
be
the
main
channel
and
the
main
way
to
communicate
either
with
the
team
or
with
any
other
uct
users
and
yeah
yeah.
I
added
the
links
to
the
chat,
so
everybody
can
get
them
directly
from
there.
Both
the
dev
talks
page
and
the
slack
channel,
and
also
the
one
related
with
the
php
storm
plug-in.
H
H
C
I
A
C
I'm
not
sure
no,
I
think
I
think
I
believe
you
can
specify
only
some
specific
folder,
no,
not
files
right
yeah.
The
thing
is
that
these
upgrade
compatibility
checks
are
based
on
the,
so
we
have
the
index
for
technically
speaking
right.
We
have
the
index
for
magento
modules
built
into
the
tool,
so
we
are
comparing
this
index
to
your
customizations,
but
we
need
to
create
the
index
for
your
custom,
custom
module
and
the
way
we
are
doing
it.
We
are
working
with
magento
modules,
so
you
should
have
a
module
to.
C
C
It's
it's
not
taking
ages
to
run
it
on
the
modules
and
then
find
the
errors
in
your
file,
but
yeah.
That's
that's
also
a
good
direction
to
for
us
to
make
upgrade
compatibility
tool
more
flexible.
I
guess
that's
something
that
is
possible
to
achieve.
We
will
see
if
we
can
just
allow
to
analyze
a
non-model,
folder
or
just
one
file.
E
Please
correct
me
if
I'm
wrong
has
understood
this
compatibility
tool
uses
the
php
version
currently
installed
on
the
instance
where
you
test
this
compatibility.
Correct,
yes,
uh-huh,
okay,
yeah
ask
this
just
because,
for
example,
we
can
have
situation
when
we
have
php
7
and
php
8
compatibility
and
in
future
php
8
for
example.1
and
php
9.0
and
in
this
case
compatibility
not
only
in
just
like
magenta
compatibility,
but
also
in
the
magenta
compatibility
in
the
specific
php
version.
So
my
question
is:
is
it
possible?
E
C
Yeah,
that's
this
question
is
actually
very
close
to
our
plans.
I
think
so
to
our
common
place
and
as
sandra
mentioned,
we
are
so.
The
the
the
goal
of
upgrade
compatibility
tool
is
simplify.
The
upgrades
make
make
the
like
minimize
the
routine
try
to
identify
all
the
common
issues
straight
away
without
the
need
to
go
and
look
in
each
file
and
for
sure
we
are
going
to
handle.