Gregory's Server... (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.
|
6 comments
 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. |
@CliftonR Well, Tusky doesn't delete the prefs on all downgrades. If it does it, it only does it when the *prefs file format* changes, which doesn't happen on all version upgrades. But it could be that Firefox's version file really does change on every single version update.