►
From YouTube: Backdrop Weekly - Sept 6th
Description
Today’s development agenda: http://bit.ly/2wyUGK8
A
This
is
our
first
meeting
after
the
backdrop
code
freeze,
so
most
of
today's
agenda
is
gonna,
be
talking
about
what
got
in
and
what
didn't
get
in
and
what
we
can
still
do
between
and
narrow
and
release.
But
before
we
get
to
backdrop
itself,
I
just
wanted
to
give
a
quick
update
on
contributed
projects.
We
have
two
new
kinship
projects
rate
and
routing
to
both
both
have
releases
in
the
last
week.
So
thanks
everybody
for
working
on
us.
Alright,
let's
turn
number
2
neat
to
review
what
went
into
backdrop.
B
Let's
see
these
have
been
rearranged
slightly,
but
I
guess
we'll
start,
maybe
with
the
exciting
ones
here.
So,
oh,
oh
sorry,
first
of
all,
let's
talk
about
the
bug,
fix
release.
Sorry,
let's
rewind
a
little
bit
one
dot.
10.2
is
the
bug
fix
release
for
1.10,
and
it
has
been
our
intention
to
make
a
release
this
past
week,
but
we
got
caught
up
with
the
feature:
freeze,
Matt
rush,
so
we're
still
hoping
to
cut
a
release
for
one
to
ten
MIT,
pretty
much
immediately.
I,
don't
think,
there's
anything
holding
us
up.
B
Okay,
now
we'll
go
on
to
111.
1.11
will
be
coming
out
here
nine
days
and
we
have
a
bucket
full
of
awesome
new
things
that
got
completed
in
the
last
week
before
feature
freeze,
first
of
all,
issued
3062
bringing
back
note.
Preview
was
carried
across
the
finish
line
and
that
enables
a
ability
to
look
at
a
preview
of
a
piece
of
content
before
it
is
saved
on
the
front
end
of
the
site.
B
What
happens
is
the
node
is
saved
into
the
temp
store
temporarily,
and
then
you
go
and
look
at
the
front
end
of
the
site
and
it
loads
the
note
as
though
it
had
been
saved,
so
you
can
have
a
preview
before
you
even
create
a
piece
of
content
for
the
first
time
before
it's
saved
into
the
like
into
the
real
database
into
the
node
table.
So
there's
follow-up
or
there
should
be
a
follow-up
to
improve
the
CSS
appearance
of
the
little
banner
that
runs
across
the
bottom
of
the
screen.
B
That
allows
you
to
save
the
piece
of
content
or
go
back
to
the
editing
screen
as
well
as
toggle
between
different
view
modes.
We
don't
actually
have
a
follow-up
for
that
one
yet,
but
we
need
to
create
one
I
think
just
because
we
know
that
there's
opportunities
for
improving
it,
but
we
don't
actually
have
any
any
suggested
designs
as
of
yet
so,
but
I
think
it
would
be
good
to
keep
tabs
on
nonetheless
to
keep
track
of
trying
to
improve
that
visually.
B
Just
a
little
bit
minor
feature
use
XF
data
to
rotate
images,
issue,
28
87
that
one
has
been
merged,
I,
don't
think,
there's
much
to
say
about
that.
One.
That's
a
handy
feature
for
people
uploading
from
my
phone
rich
text
editor
file,
browser
making
it
so
that
you
can
browse
and
reuse
images
that
are
provided
via
a
configurable
view,
issue
31
34
that
one
was
completed
and
merged
in
this
past
week.
There
is
a
follow
up
that
herb
dual
filed.
32
is
76.
B
That
is,
there's
a
bug,
sometimes
when
updating
images,
if
you
follow
certain
steps,
replacing
an
image
with
another
one-
sometimes
houses
the
JavaScript
air.
So
we
need
to
get
that
one
resolved
before
1.12
for
certain,
because
that's
not
a
friendly
bug
to
have
in
one
of
our
key
features
for
112,
so
3276
could
definitely
use
some
eyeballs
figuring
out.
Why
that
javascript
error
occurs
and
how
we
can
fix
it.
B
Let's
see
contact
module,
a
contact,
module
didn't
actually
have
any
changes
this
past
week,
but
I'll
reiterate
it
again.
Oh
did
actually
the
last
two
items:
permissions
on
the
contact
settings
forum,
issue,
31,
90
and
better
messaging
for
saving
contact
module
settings
2257
both
of
those
were
merged
prior
to
feature
freeze.
So
that's
awesome.
Thanks
again
Obie
for
all
of
your
work,
putting
the
other
improvements
for
contact
module.
B
Let's
see
color
module
improvements
issued
1905.
There
hasn't
been
any
changes
to
this
issue
in
the
past
week,
but
we
do
have
some
follow-ups
32:57,
allowing
for
greater
flexibility
within
the
color
form
that
one
Joseph
and
I
have
been
going
back
and
forth
on
that
one,
whether
or
not
we
need
to
change
something
there.
There's
some
good
ideas
that
we
might
trim
down
that
pull
request
to
two
just
improve
the
code.
Styling
just
a
little
bit
and
issue
3209
is
a
follow
up
for
adding
predefined
color
schemes
to
basis
out
of
the
box.
B
So
basis
is
now
colorize
a
bowl,
but
it
doesn't
include
any
out-of-the-box
themes.
This
issue,
3209,
can
still
be
done
before
feature
freeze
because
it's
not
actually
adding
any
real
code.
If
you
will
it's,
it's
just
adding
some
predefined
list
of
colors,
basically
so
considering
the
very
low
risk
of
that
one
and
it
not
actually
impacting
any
functionality
anywhere
that
one
is
still
a
candidate
for
1.12.
B
B
That
makes
it
so
that
we
have
a
trimmed-down
functionality,
that's
akin
to
rabbit
hole
that
you
can
enable
per
content
type.
The
ability
to
just
hide
the
page
path
from
front
from
the
front
end
or
from
your
from
your
visitors,
it's
not
as
flexible
as
grab
a
hole.
You
don't
have
options
for
redirecting
or
for
showing
different
types
of
of
page,
not
found
options.
It
merely
makes
the
path
basically
disappear
for
users
that
don't
have
the
view.
Pathless
nodes
permission,
I,
think
that's
it.
B
Few
pathless
I
can't
quite
remember
what
a
what
the
terminology
was
there
we
did.
It
I
have
a
lot
of
back
and
forth
on
wording
there.
That
was
the
greatest
contention,
and
that
issue
is
your
thing:
I
went
to
name
things,
but
anyway
it's
very
exciting.
We
will
need
to
do
some
work
on
rabbit
hole
to
make
it
so
that
rabbit
hole
and
that
new
feature
don't
conflict
too
badly.
Well
end
up
happening
right
now.
B
If
you
already
have
rabbit
hole
on
your
site
and
you
upgrade
rabbit,
a
little
continues
to
be
enabled
and
nothing
changes
essentially,
but
now
there
are
two
ways
to
to
block
access
to
a
nodes
path.
You
can
either
use
rabbit
hole
as
you
were
using
previously,
or
you
can
use
this
new
core
option
and
if
either
one
of
them
are
enabled
it
will
block
access
to
the
node
path.
I
would
not
really
recommend
doing
both
at
the
same
time.
B
Let's
see,
we
also
have
a
follow-up
that
was
filed
after
that
was
merged.
Issued
3275
is
a
usability
improvement,
slash
bug
that
if
a
user
doesn't
have
access
to
view
the
node
that
they
just
created,
then
we
need
to
redirect
back
to
the
Edit
form
rather
than
taking
them
to
a
page.
That
says
the
page
is
not
found,
because
that's
that's
just
confusing,
so
that
issue
is
3275
a
bug
that
needs
to
be
resolved
in
the
next
week
before
release
before
we
release
1.12.
B
I
also
got
a
question
here
from
Gitter.
That's
like
what's
the
last
possible
date
for
adding
predefined
color
schemes
to
basis
issues
3209
well
last
possible
date
is
probably
the
day
before
release.
Probably
the
14th
I,
don't
really
like
breaking
things
on
the
day
of
release.
It
just
doesn't
leave
enough,
but
it's
prone
to
causing
accidents
doing
that,
so
the
14th
is
probably
the
last
date
for
that.
Oh
sorry,
yes
and
they're,
really
so
1,
not
11,
not
1,
12,
sorry,
okay,
that's
it!
For
pages
nodes!
B
We
had
a
real
strong
push
right
at
the
end
of
the
cycle
for
adding
feel
double
file,
bundles,
which
is
a
major
component
of
file,
entity,
module
and
media
module
from
Drupal
7.
That's
issue:
26
32.
We
got
to
the
point
that
I'll
test
for
passing
we'd
fixed,
merge
conflicts.
We
had
a
lot
of
great
code
reviews,
but
that
feature
just
wasn't
quite
ready
for
1.11.
It
could
be
one
of
our
first
issues
for
1.12.
B
It
really
is
an
excellent
shape,
but
it's
a
massive
massive
amount
of
code
and
I
think
we
felt
that
we
weren't
ready
to,
or
we
weren't
going
to
try
to
attempt
to
rush
in
that
massive
porting,
the
file
inity
into
into
core
on
such
short
notice.
The
good
news
is:
is
that
because
most
of
it
is
in
that
is
the
straight
port
out
of
Drupal
7.
Most
of
its
functionality
has
been
extensively
tested
in
the
triple
7
cycle,
and
this
is
mostly
just
a
cross
port
over
to
backdrop.
B
B
B
So
that
means
that
if
you
want
to
test
out
this
functionality,
which
is
what
a
lot
of
us
community
members
are
going
to
be
doing,
that
worked
on
this
feature,
you
can
edit
the
installer
Don
settings
that
Jason
file
the
config
file
to
enable
the
ability
to
turn
on
core
updates,
and
so
that
main
functionality
that
we've
been
talking
about,
that
we
thought
that
was
ready
for
weeks
or
even
months
now
we
merged
that
in.
But
we
and
then
we
filed
a
follow-up
issues
3271
to
enable
that
functionality
by
default
in
1.12.
B
There's
also
some
other
discussion
in
there
that
potentially
we
could
make
it
so
that
you
could
turn
on
and
off
all
of
the
installer
capabilities
like.
Maybe
it
would
be
useful
to
allow
users
to
update
their
modules
but
disallow
the
ability
to
install
new
modules,
for
example,
and
so
we
could
provide
settings
for
every
individual
type
of
extension
and
whether
or
not
you
could
install
or
update
it.
B
So
that's
it
for
the
core
updates
there.
There
is
still
the
issue
tracker
for
1.11
issues:
I,
don't
think
that
we've
cleaned
it
up
quite
yet,
but
I
think
we'll
do
that
shortly:
bumping
everything
that
didn't
get
completed
into
1.12
or
putting
it
back
into
the
general
one
dot
X
pool.
Do
you
have
anything
to
say
about
that?
Jen.
A
B
Yeah
we
allow
UX
improvements,
even
between
bug,
fix
versions,
so
like
1.11
does
ero
and
one
dot,
11.1,
1.1,
1.1
and
so
yeah.
We
do
allow
that
before
code
freeze
or
before
release
as
well,
but
we
try
to
limit
it
purely
because
we
don't
want
to
introduce
any
kind
of
regressions,
mu,
X
changes,
even
though
they're
allowed
they
could
potentially
cause.
B
A
So
some
of
them
are
pretty
clear
that,
like
it's
gonna,
be
a
good
feature
and
I
think
our
roll
last
release
Nate
was
that
if
it
needed
additional
testing,
then
it
couldn't
go
in
so
I'll
try
and
do
a
first
prune
of
the
list
and
pick
the
ones
that
definitely
aren't
gonna
make
it,
but
it
would
be
good
to
you
know,
check
some
other
wants
and
be
like
how
big
the
features
this
is.
This
still
possible.
B
Ideally,
you
know
that
list
should
only
contain,
like
you
know,
two
or
three
things,
because
it
really
should
be
like
these
are
the
last
couple
of
issues
that
prepare
us
for
release
next
week
is
that
next
week
it's
next
weekend,
so
it's
kind
of
close
enough
yeah
also
case
you're,
curious,
September,
15
plants
on
a
Saturday,
but
unlike
feature
freeze,
which
we
tend
to
allow
for
the
extra
weekend
releases,
are
always
exactly
on
the
15th
of
the
release
month.
So
backdrop
1.11
will
be
September
15th,
even
though
it's
on
a
Saturday,
so
just
FYI.
B
A
B
C
But
if
you
look
at
the
way
that
looks
in
the
dashboard
now
the
commit
messages
aren't
being
refactored
in
a
way
that
translates
what
they
are,
what
they
mean
to
the
Pantheon
users.
I,
don't
think
you
know
there
aren't
so
many
of
us
now,
but
that
needs
to
be
factored
into
the
merge
process,
because
if
you
just
merge
it
with
the
commit
message
that
was
on
it
before
when
it
shows
up
in
the
dashboard,
it
isn't
always
clear.
B
C
A
C
The
only
thing
open,
I
think
is
really
the
drush
compatibility,
there's
still
more
work
to
do.
None
of
those
are
ready
to
go
right
and
I.
Think
the
problem
is
you
identified
a
while
ago
is
with
the
Pantheon
configuration
with
this.
Not
with
the
approach
verb
is
using
works,
but
it's
a
lot
of
files
and
very
messy
so
hoping
that
Greg
can
tune
back
in
and
get
that
and
they
seem
to
be
really
responsive
to
organizational
upstreams
actually
getting
this
to
work.
So
so
that's
good!
C
A
B
Yeah,
to
recap,
a
couple
of
things:
Kevin
that
were
included
I
urged
in
support
cause
number
24
from
the
backdrop
Pantheon
repo
that
adds
the
Pantheon
API
module
and,
like
you
said,
whatever,
whatever
the
commit
message
is
as
soon
as
it
gets
merged
into
the
master
branch.
That
immediately
shows
up
as
an
upstream
update
on
everybody
that
has
a
backdrop
project
on
Pantheon
and
so
when
I
emerge,
that
pull
request.
B
I
also
like
updated
the
commit
message
to
make
it
a
little
bit
more
end
user
friendly,
because
the
commitments
which
shows
up
literally
in
the
fact
other
than
the
Pantheon
dashboard,
so
I
think.
As
far
as
the
maintainer
czar
concerned,
we
should
instigate
some
kind
of
policy
around
like
when
you
merge
always
squash
and
when
you
squash
make
sure
that
it's
a
message
that
his
end
user
friendly
make
it
so
that
yeah
that
they
show
up
properly.
It
is
a
also
a
little
bit
challenging
that
literally
every
commit.
You
know.
C
B
A
No,
so
the
only
real
incentive
for
doing
that
would
be
if
you
could
move
your
configuration
files
outside
of
the
doc
root,
but
you
can't
do
that
on
Pantheon,
because
you
can't
get
anything.
That's
writable,
that's
not
the
files
directory
mm-hmm.
So
we
have
to
solve
that
problem
first
or
we
don't
have
to,
but
it
would
make
sense
to
do
those
things
together,
rather
than
just
moving
files
around
without
any
other
gain.
Okay,.
B
B
Versioning
yeah,
that
was
it
okay,
so,
let's
put
it
put
okay,
that's
it
for
the
1.11
update.
Now
this
is
not
official.
This
is
just
crazy
idea
that
I've
been
bouncing
around
and
it
has
to
do
with
breaking
compatibility
with
backdrop
in
that
or
with
the
previous
versions
of
backdrop
and
I
think
we've
talked
about.
You
know,
winnable
backdrop
to
happen.
If
it's
you
know
like,
and
what
does
that
mean
like?
Are
we
ready
to
break
compatibility
with
all
of
the
Trib
which
were
not
right
now,
but
in
the
future
like?
When?
B
B
That's
deprecated
is
now
all
gone,
and
everybody
has
to
update
their
contributors
all
at
the
same
time
to
say
that
they're
backed
up
to
compatible
the
crazy
idea
that
I
have
is
that,
instead
of
having
a
major
break
like
that,
that
comes
every
couple
of
years
that
causes
this
massive
upgrade
headache
for
everybody.
All
at
once
is
that
we
pivot
from
the
concept
of
major
releases
on
a
very
long
interval.
B
To
every
backdrop,
minor
release
is
a
major
release,
and
so
basically
we
lock
the
one
off
of
backdrop,
and
we
say
the
next
release
theoretically
would
be
back
drop
twelve,
followed
by
backup
thirteen
followed
by
back
to
fourteen
and
we
adopt
the
model.
The
browser's
have
adopted
that
you
know
we're
on.
B
The
span
of
things
being
deprecated
becomes
much
longer,
so
it
makes
it
so
that
we
can
deprecated
functionality
and
then
based
on
the
popularity
or
usage
of
that
feature,
we
can
drop
it
at
some
arbitrary
time
into
the
future.
So
we
might
have
20
releases
of
backdrop
before
we
drop
a
deprecated
feature,
or
we
might
only
have
four
releases
a
backdrop
before
we
have
a
deprecated
feature,
and
this
allows
us
to
drop
deprecated
functionality
in
a
staggered
manner.
Instead
of
having
one
massive
API
break,
that
happens
all
at
once.
B
It
does
also
mean
that
modules
would
probably
say
it
would
work
under
the
assumption
that
they
always
work
forever.
There
would
never
be
a
like
backdrop
to
where
it
was
assumed
that
compatibility
was
broken.
Instead,
compatibility
would
be
assumed
up
until
a
certain
point
and
then,
if,
if
a
particular
feature
were
deprecated
or
removed,
we
could
potentially
detect
or
use
that
to
say
like
these
features
like
these
modules
are
no
longer
compatible
because
they
use
the
deprecated
features
that
were
removed.
I,
don't
know
if
how
automated
we
can.
A
Then,
in
a
module,
you
would
say
you
would
add
like
to
your
info
file
for
like
if
I
already
have
like
1.6.
Oh
I
would
have
to
add
to
my
info
file
for
1.6.
That
only
works
up
to
backdrop
so
like,
for
example,
let's
pretend
it's
rabbit
hole
right
and
we
just
added
some
new
feature
into
112
for
rabbit
hole
or
one
yeah.
A
Well,
112
we
on
now,
if
used
anyway,
we
had
a
new
feature,
but
then
I
want
the
old
version
of
rabbit
hole
to
only
work
up
to
the
today's
version
of
backdrop
and
tomorrow's
version
of
backdrop.
My
I
need
a
new
version
of
rabbit
hole,
and
so
the
new
version
would
say
starts
at
like
112
plus,
but
the
old
version
would
need
to
say
112
like
111
and
I'm
lower
yeah
yeah.
And
how
do
you
then
add
that
change
to
an
existing
version
of
a
module?
You
probably.
A
A
B
A
I,
like
this
crazy
idea
of
backwards-compatibility,
where
everything
becomes
deprecated
before
it
gets
removed,
and
we
can't
just
change
something
that
breaks
without
some
kind
of
compatibility
layer
I'm
a
little
bit
worried
that
that
might
not
always
be
possible
depending
on
the
kinds
of
things
we
want
to
change,
and
that
was
why,
when
we
originally
made
our
principles,
we
didn't
say
100%
always
backwards
compatible.
Like
WordPress
said,
we
said
it's
important
because
we
felt
like
there
were
some
significant
things.
A
We
were
changing
where
that
kind
of
change
was
gonna,
be
necessary,
so
I
think
like
over
the
past
four
years,
we've
proven
that
we
can
do
an
awful
lot
with
marking
things
deprecated
and
adding
new
things,
but
I
wonder
where
that
limit
is
and
if
we're
gonna
end
up
limiting
back
drop.
If
we
commit
to
never
doing
that
or
what
how
we
would
handle
it
when
we
do
need
to
make
that
kind
of
change,
I.
A
I
think
for
the
short
term,
I
would
prefer
to
stick
with
our
current
numbering,
but
adopt
the
policy
of
deprecated
first
remove
later,
as
like
an
official
policy
and
continue
with
that
for
I,
don't
know
the
first
thing
foreseeable
future
and
when
we
decide
we
can't
go
on
without
major
API
changed.
We
figure
out
how
to
how
to
do
that
in
a
way.
That's
least
impactful
to
people
running
backdrop,
and
if
that
means
at
that
point
we
commit
to
like.
Oh
we're
on.
B
Yeah,
the
one
key
thing
that
that
I
I'm,
trying
to
figure
out
a
way
around
is
the
like
sudden.
You
know
the
dropping
of
a
new
version
of
backdrop
that
potentially
might
not
even
include
any
new
features
that
just
removes
all
the
deprecated
stuff
and
then
every
module
out
there
all
has
to
you
know,
update
basically
but
I,
don't
know
I,
don't.
A
B
A
A
B
One
of
the
things
that
we
have
set
up
currently,
though,
is
that
backdrop
itself
and
the
way
the
project
module
works
is
that
it
will
segment
by
major
version.
So
if
you
are
a
maintainer,
you
would
be
required
to
have
the
backup
version
of
your
module
and
the
backup
one
version
of
your
module,
even
if
they
were
the
same
thing,
which
is
a
little
a
little
strange.
We.
B
A
B
A
There's
a
lot
of
I
think
a
lot
of
technical
challenges
which
everywhere
we
go,
but
I
think
it
is
good
for
us
to
think
about.
Like
you
know,
we
have
this
commitment
to
backwards.
Compatibility
we've
been
able
to
get
a
really
long
way
in
four
years
by
adding
features
without
needing
to
do
any
API
breaks.
A
Let's
take
a
look
at
the
way
that
your
post
historically
done
it
and
figure
out,
if
that's
still
a
good
match
for
what
backdrops
can
be
doing
in
the
future,
and
if
not,
you
know,
let's
play
with
some
of
these
other
options
and
see
like.
Is
it
possible
to
support
two
major
versions?
It's
impossible
to
drop
the
major
version
number
like
what?
What
are
the
ramifications
of
each
of
those
things
I'm
through
so
I
like
crazy
ideas,
because
sometimes
they
make
you
land
on
something,
not
crazy,
that
you
wouldn't
have
thought
of.
B
B
Okay,
well,
that
was
the
crazy
idea,
if
just
so
I'm
going
to
kick
around
out
there.
For
all
of
you
backdrop,
peeps
out
there
I
said
yeah
I've
been
kicking
it
around
and
I
pitched
it
to
gem
this
past
week
and
it
would
didn't
come
out
as
crazy
as
it
sounded
in
my
head
was
so
I
was
good,
so
we
thought
we'd.
A
B
B
Yeah-
and
you
know,
one
of
the
things
that
makes
me
think
about
this
way
is
that
we
do.
We
have
had
I,
think
maybe
a
half
dozen
API
breaks
since
backdrop.
One
came
out,
there
have
been
minor,
but
they
have
occurred,
and
that
means
that
some
modules-
some
exceptional
situations,
you
might
not
be
able
to
update
from
backup
1.2
to
1.3,
because
there
was
some
minor
API
break
in
there,
and
so
that
means
that
at
least
a
couple
of
times
we've
treated
minor
versions
as
majors.
B
They
really
should
have
been
majors,
and
if
you
wanted
to
get
really
stickler
about
our
semantic
versioning
we're
not
doing
it
right
and
if
you
bump
the
major
version
every
release,
then
that
would
allow
us
to
do
those
minor
releases
and
have
them
actually
be
semantic
versioning,
even
though
we
would
still
minimize
it
as
much
as
possible.
So
we
basically
would
continue
doing
exactly
what
we're
doing
right
now,
every
major
version
wouldn't
be
guaranteed
to
have
API
breaks.
It
would
just
like
every
time
you
added
new
features.
B
There
would
be
another
major
instead
of
the
way
that
we're
handling
it.
Now
we
some
cheat
every
now
and
then-
and
we
include
UX
features
and
bug-fix
releases,
and
if
we
switch
to
this,
that
UX
features
or
string
changes.
For
example,
my
end
up
being
in
the
minor
releases
and
bug
fixes
would
literally
be
exclusively
bug
fixes,
so
it
would
make
it
so
that
we
would
actually
follow
the
rules
of
semantic
versioning.
Even
if
we
didn't
yeah,
we
would
take
the
idea
of
major
versions,
and
there
wouldn't
really
be
that
that
major.
A
I
think
the
only
problem
I
have
with
that
is
like
conceptually
the
idea
of
doing
a
major
version.
Update,
stresses
me
out,
and
probably
anyone
that
comes
from
Drupal
would
be
stressed
out
by
that
thought,
and
so
we
would
need
to
do
a
really
good
job
of
making
sure
to
communicate
like
no.
It's
the
same
thing
that
you've
been
dealing
with
backdrop
since
the
beginning,
nothing's
gonna
change,
except
for
the
numbers
and
also
have
like
really
clearly
defined.
B
Yeah
and
every
now
and
then
there
would
be
the
inevitable.
You
know
large
deprecation
that
actually
did
get
removed
akin
to
Firefox
quantum
coming
out
and
dropping
support
for
their
old
plug-in
system,
for
example,
or
or
I.
Guess,
prior
to
that,
you
know
like
when
Google
hangout
stopped
for
Chiquito
like
every
now
and
then
there
would
be
a
dreaded
release
that
was
like.
Oh,
you
can't
go
past
version
40
because
all
kinds
of
stuff
breaks,
then
you
know
so
yeah
I,
don't
know:
okay,
let's,
let's,
let's
drop
it
and
be
done
with
that.
B
A
I
just
wanted
to
thank
everybody
who
is
working
so
hard
over
the
weekend
on
all
of
the
amazing
new
features
that
are
going
into
the
next
version
of
backup,
especially
a
huge
flurry
of
activity,
not
just
over
the
weekend
actually
the
last
few
weeks.
So
it's
really
great
to
see
that
yeah.
B
And,
and
even
more
so
perhaps
to
the
people
that
worked
so
hard
on
features
that
didn't
make
it.
You
know,
thank
you
for
your
patience
and
you
for
your
effort
working
on
those
things
that
well,
you
know
we'll
try
our
best
to
get
it
into
the
next
release
and
sorry
about
any
disappointment.
You
may
have
felt
about
getting
your
feature
in,
but
it's
a
great
thing
about
you
know
three
times
a
year
releases.
B
Is
that
there's
always
the
next
one
in
this
only
four
months
away,
so
yeah
thanks
I
have
my
thanks
to
everybody
that
worked
on
this
release.
It's
been
very
exciting
and
I.
Think
1.11,
it's
gonna
be
pretty
kick-ass.
So
thank
you,
yeah,
okay,
all
right!
Well,
let's
not
celebrate
too
soon.
We
still
have
one
more
week
to
go
so,
let's,
let's
keep
working
and
make
London
11
great.
So
thanks
everybody!
You
guys
next
week.