On Thursday, March 16, 2017 at 12:16:24 PM UTC-7, Benjamin Smedberg wrote:
> users that reverted to an older version, staying on the release channel:
> 2.19%
Benjamin, two further questions, one of which I think you can answer, and one
you probably can't:
- As Dolske asked: what proportion down
It would be useful to know if most of those users are just downgrading the
previous version (N-1 for release, N-7 for ESR), and how quickly they
return to a current release (assuming they do!).
This would help inform to what degree we need to support (and test!) the
myriad combinations of upgrade-
I apologize for the delays in bug 1246615. It fell off my radar with a
series of trips. I've set up a meeting tomorrow to at least identify who is
responsible for this decision, because it's not exactly me. I analyzed some
data in the bug which I'll repeat here.
Here is an analysis of the patterns
> As an example of why "backup the db" is harder than it sounds, you would
> need to backup the entire storage subsystem.
Mossop suggested I chime in on this thread, but I think Ben has covered much of
what I'd say!
Some set of schema changes is safe or possible to downgrade: rearranging
deckc
On 2017-03-07 8:02 PM, Ben Kelly wrote:
> On Tue, Mar 7, 2017 at 6:09 PM, Xidorn Quan wrote:
>
>>> This major version change is downgrade-incompatible, so IndexedDB and
>>> DOM cache won't work in an older version if their profile has been
>>> upgraded.
>>> IndexedDB is also used internally, so s
On 2017-03-07 7:09 PM, Mike Hommey wrote:
While talking about this... I think it's about time we had an actual
plan for data cleanup.
Last week, when the cloudflare thing happened, I went through the files
in my profile looking for all my password-manager-managed passwords and
the domains associ
On Tue, Mar 07, 2017 at 08:02:47PM -0500, Ben Kelly wrote:
As an example of why "backup the db" is harder than it sounds, you would
need to backup the entire storage subsystem. If you lose data in IDB, but
don't lose data in other sub-systems like cache API, then an origin can
find itself in a c
On Tue, Mar 7, 2017 at 6:09 PM, Xidorn Quan wrote:
> > This major version change is downgrade-incompatible, so IndexedDB and
> > DOM cache won't work in an older version if their profile has been
> > upgraded.
> > IndexedDB is also used internally, so stuff that depends on it likely
> > won't wor
On Wed, Mar 08, 2017 at 10:09:52AM +1100, Xidorn Quan wrote:
> On Wed, Mar 8, 2017, at 09:59 AM, Jan Varga wrote:
> > On 07/03/17 23:43, Robert Strong wrote:
> > > Are there any problems experienced by clients that downgrade to an
> > > older version after their profile has been upgraded?
> > >
>
On Wed, Mar 8, 2017, at 09:59 AM, Jan Varga wrote:
> On 07/03/17 23:43, Robert Strong wrote:
> > Are there any problems experienced by clients that downgrade to an
> > older version after their profile has been upgraded?
> >
> This major version change is downgrade-incompatible, so IndexedDB and
On 07/03/17 23:43, Robert Strong wrote:
Are there any problems experienced by clients that downgrade to an
older version after their profile has been upgraded?
This major version change is downgrade-incompatible, so IndexedDB and
DOM cache won't work in an older version if their profile has be
Are there any problems experienced by clients that downgrade to an older
version after their profile has been upgraded?
Thanks,
Robert
On Tue, Mar 7, 2017 at 2:32 PM, Jan Varga wrote:
> Since the integration of bug 1339081 [1] in Nightly, the storage has
> been upgraded from version 1.0 to 2.
Since the integration of bug 1339081 [1] in Nightly, the storage has
been upgraded from version 1.0 to 2.0
This means that if you run an already upgraded profile (by current
Nightly) in an older version of Firefox, then any storage APIs that
use Quota Manager (especially IndexedDB and DOM cache
13 matches
Mail list logo
