| General > General Technical Chat |
| Preserving settings over a firmware upgrade |
| << < (6/8) > >> |
| Siwastaja:
--- Quote from: nctnico on July 28, 2023, 08:28:25 am ---That is the cost of backward compatibility. For sure everyone will agree that it is better to avoid needing such migrations but either way it is better to prepare the way the data is stored so that software can detect the settings are compatible or not. When the configuration data is incompatible between versions, the next question is whether to use sensible defaults or try to convert. --- End quote --- Yeah. And while it would be nice to plan all the future features/fixes in advance and come up with perfect set of settings from day 1, it will only happen for a really simple product or a product which does not need much updates. In which case OP would not be asking. Better mentally prepare for significant changes. On the other hand, I also prefer just-in-time principle for development: if you know you will be able to pull off migration code when needed, then do it only when needed. Simply, when the day comes that you have to break the compatibility, add the migration code then. Test it well before releasing the update in the wild. If you are lucky, you never need to do that. Even if you have to, you are then better off than trying to come up with the scheme 2 years earlier. And simple structs lend themselves very well for such migration functions, as shown above in code examples by me or DavidAlfa: all you need are the constructs available in the programming language you are using in that project anyway. |
| Kalvin:
The settings needs to be compatible both ways: - The settings need to be preserved when upgrading to a newer version. - The settings need to be backwards compatible when downgrading to an older version so that downgrading won't break those settings values that are shared between releases. If the settings cannot be preserved over upgrade/downgrade, the firmware should provide good default values for those settings that cannot be preserved. |
| DavidAlfa:
50% simpler: Don't allow downgrading! |
| Siwastaja:
--- Quote from: Kalvin on July 28, 2023, 12:30:09 pm ---The settings needs to be compatible both ways: - The settings need to be preserved when upgrading to a newer version. - The settings need to be backwards compatible when downgrading to an older version so that downgrading won't break those settings values that are shared between releases. If the settings cannot be preserved over upgrade/downgrade, the firmware should provide good default values for those settings that cannot be preserved. --- End quote --- I would not generally agree. It's a sensible decision not to allow downgrading, to KISS, especially in a cheap commodity product. (Much more limiting decisions are made all the time.) For a special industrial expensive gizmo, that might be desirable for some weird reason customer might have, but then you can sell the downgrade work, along with generating new settings, as specialized work and the customer would pay for it. If downgrading is required for troubleshooting, then that can involve manually working out the correct settings. When the problem that required the downgrade is found, it can be applied to the new version so that the reason for downgrade goes away. |
| Kalvin:
--- 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. |
| Navigation |
| Message Index |
| Next page |
| Previous page |