|
Top-level
 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. 4 comments
 @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
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.
* Section # N includes all prefs vN supports, so any fairly stable pref is preserved.
* All newer prefs go into a section by SW version which added them.