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 of people downgrading: https://gist.github.com/bsmedberg/1af70857106bfe29128a0e8d0b656804 - this analysis was reviewed by chutten users that switched channels at all: 0.48% users that reverted to an older version: 2.55% users that reverted to an older version, staying on the release channel: 2.19% Downgrades are more prevalent than I thought, and channel-switching is not a primary factor in downgrades. So the ideas that we would mostly solve this problem by giving channels separate profiles appears to be false. I still believe that we should do our best to make some set of downgrades seamless for the user (if perhaps with some reversion to prior data or duplicating). And that showing people a banner warning is user-hostile in the sense that if they downgraded it was probably for a reason and so they aren't going "back". What I'd like is some clearer guidance about how much we should support downgraders and how much engineering effort we should put into making downgrade as painless as possible. --BDS On Wed, Mar 8, 2017 at 9:40 AM, Ehsan Akhgari <ehsan.akhg...@gmail.com> wrote: > On 2017-03-07 8:02 PM, Ben Kelly wrote: > > On Tue, Mar 7, 2017 at 6:09 PM, Xidorn Quan <m...@upsuper.org> 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 work too. > >>> There's bug 1246615 [2] where you can find a discussion related to this > >>> issue. > >> > >> It would probably be a good idea to backup the old files when upgrading, > >> so that old version can at least pick the backup file to use. > >> > > > > Maintaining downgrade compatibility is a lot more complex than people > think > > Yes. > > > and we have zero test support for it. > > This part isn't entirely true. > > The full picture is a bit more complex. Some components have supported > full downgrades with automated tests running on the infrastructure for > years. Examples are the cookie manager and the permission manager. > Other components have intentionally decided that it's OK to not maintain > backwards compatibility, for example, IndexedDB. In other places, > people (myself included) have just not been careful enough and have > (either intentionally or unintentionally) landed code that isn't > downgrade compatible. > > It's certainly true that in general there is no tests that would catch > you if you land code that breaks a downgrade scenario, and over the > years it has become quite clear that maintaining a downgrade-compatible > browser is impractical. > > I agree with Ben, Jan and others that this situation is unsustainable, > and we have to do something about it. I also agree with Xidorn about > how bad it is that we risk destroying data from the very subset of our > user population who go out of their way to help us by testing changes on > newer builds and risk losing their data when going back to an older build. > > To be perfectly honest, the situation in bug 1246615 is quite > frustrating. I no longer understand what we are waiting for in that > bug. It seems like that bug is being scope creeped into a larger plan > (based on comment 29 there) and still unclear what that exactly means, > and here we are now: while Firefox 55 rides the trains, we *will* > destroy our community's browsing data as they help us test Firefox. > > Benjamin, can we please address this with the urgency it deserves? > Thank you for your attention. > > Cheers, > Ehsan > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
