|
Top-level
 FWIW this isn't yet in the ESR version. (Extended Support Release, targeted at corporations but better for everybody who doesn't want rapid changes.) I would recommend switching to the ESR version, as a temporary step to buy time while you figure out the longer-term plan *EXCEPT* (big but!) there's a huge problem with that measure. + 12 comments
It's a very user-hostile move, isn't well-explained, and doesn't even hint at ways to work around or undo it. Edit: And frequently, the reality is that there is no particular incompatibility. So much of the time, it's trashing settings and customizations people have built up over years, over nothing. Very ill-considered, though nothing compared to this adtech move.  @CliftonR Uh, hm. Well I can definitely as a developer understand why a preferences file downgrade could lead to hard-to-understand bugs that you would not want to even *try* to anticipate. Tusky, the app I work on, would do the same in this situation (and this has caused me problems during development). But there *are* ways they could do notification, or print out a user-readable version of the prefs they're throwing away, and it doesn't sound like they're doing that. Yes, as a developer I understand the issues they're trying to avoid, and your examples are exactly the kind of thing I was thinking of. Or put up a dialog saying "If you want to keep your old profile, this has some serious risks [blah-blah-blah]" with choices for Probably one could build something to diff the supported settings. + @CliftonR I've been thinking about workarounds, I promise! Very few of our users ever get bit by this because version rollbacks are rare, but *I* get hit by it all the time because I'm always rapid-fire testing different prerelease builds. Maybe I'll think about this some more… like maybe we could include a version converter (Kotlin feature) to rollback to a very old version, and then roll back forward again from there. That might at least allow you to preserve your logins and drafts. ... (as in supported across different versions) and only threaten to scrap them if they're different. But this is supposed to be a rare use-case, and nobody wants to design for that. I get that. Yeah, I wasn't thinking about what you're doing with Tusky, though it's obvious why it's in the forefront of your thoughts. Having a version number for your pref format and checking it's <= the supported version is an eminently sensible starting point. I implemented something similar to that at $DAYJOB for configuration/pref files years ago. I'm mostly just musing about how Firefox could do better if they wanted to. This gave me an idea you could play with for Tusky, for your case where you frequently roll backwards/forwards: Instead of versioning a pref file as a whole, suppose you versioned it by sections? E.g, start with a recent past version, vN: * Section # 0 is baseline preferences, that all versions support and you can always preserve. @CliftonR Thank you for the thought but we're using a particular system. We didn't create our own prefs/persistence format, we're using an Android feature called "Rooms". It's basically managing an sql database for us, changing "file formats" means running some sql ALTER TABLEs, and upgrade means running the registered ALTERs in a particular order (and Android decides which upgrade SQLs to run). So to improve things we'll have to work within this system. |
Gregory's Server
@mcc
If you're not already using ESR, the experience of switching is horrible.
When I did this to work around a Firefox bug which broke some of my constantly-used extensions, I found:
If you switch from a newer version to an "older" major rev, Firefox deliberately discards *all* of your settings and personalization, on the grounds that the new ones *might* possibly be incompatible.
AFAICT restoring them requires figuring out the profile files and their format and editing them directly.
+