General > General Technical Chat
Preserving settings over a firmware upgrade
<< < (7/8) > >>
AndyC_772:
I'm inclined to favour:


--- Code: ---if (nv.settings_version < CURRENT_SETTINGS_VERSION)
  migrate_settings();

if (nv.settings_version > CURRENT_SETTINGS_VERSION)
  factory_default();

--- End code ---

Downgrading firmware isn't something I'd look to explicitly lock out, but it doesn't need to be so graceful.
PlainName:
I've upgraded a lot of stuff I wish could  be downgraded to fix new bugs or unwanted features. Altium is a great example: doesn't care what version of software you're running and will tell you if a new feature can't be handled in an old version (obviously, with an embedded device it can't do that, but it can ignore the new data). Altium 09 can be used to view Altium 23 documents perfectly well, despite the features introduced in the intervening 16 years.

I have similar software, and I love 'em. For the user they are pain free, and these things should be designed for the user, not the developer. In contrast, there is stuff I can't allow to be updated because there is no way back, and I hate 'em.

pfSense is middle of the road. You can export settings, update (or install somewhere else) and import. The worst I've had has been the Ethernet interfaces changing names, so the low level network IDs have to be frigged about with. But the bulk of the settings have been fine. But look at Tweetduck - minor update and it can't import settings from the previous version. Another one I used to not allow to update (pointless now since it no longer works, thanks to Musk).
Siwastaja:

--- Quote from: Kalvin on July 28, 2023, 12:41:40 pm ---
--- Quote from: DavidAlfa on July 28, 2023, 12:31:04 pm ---50% simpler: Don't allow downgrading!

--- End quote ---

If the settings management is done rightTM, then it really doesn't increase complexity that much.

--- End quote ---

Settings management (how to store them) is the trivial part (unless you colossally fucked it up, of course). The problem is always in functionality (what the settings signify and how). There must be a reason why a new version with incompatible conf came out: it does something the old version did not do at all, or does some new thing better, and conf is somehow related to these changes. Now there also must be some reason why the new version is in use, and configured to do something. You would need to transform these new settings to something that does as close to the right thing as possible, using that old version. This is a lot of work for little gain, because going back in versions would be quite rare.

Therefore, I second AndyC's suggestion that downgrading would be handled with factory defaults. As downgrading is a special measure against something anyway, manually changing settings is not a big deal.
PlainName:

--- Quote ---manually changing settings is not a big deal
--- End quote ---

Depends on how many, what they are, and the device. Some devices are so bleeding tedious to change anything you really don't want to do that very often, and with many devices you can't remember what you've changed since you spent that week setting it up 2 years ago (because, no export remember). That viewpoint - the user won't mind doing it all again - is what keeps stuff on old versions. If you're lucky the user will update once before finding out the best thing is to not do it again.
thm_w:

--- Quote from: Shonky on July 28, 2023, 11:16:32 am ---Full source linked at the end?

--- End quote ---

Not licensed as open source.
Navigation
Message Index
Next page
Previous page
There was an error while thanking
Thanking...

Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod