Firmware update, settings migration

[vanBassum]

Hello,

I have the following (hypothetical) scenario:
In V1 the settings are stored using NVS.
In V2 the settings are stored to FAT using JSON.

Now, when V1 is running in the field and a firmware update comes along, the settings from the NVS should be converted, so the system keeps running with the right settings. For this, I created the following scheme:

A migration manager that contains a list of migrations. These migrations can execute some custom code after updating. In the above example, one migration would be required:
- V1 to V2 (Migrate settings from NVS to JSON)

Now, there are 2 scenarios when the device boots with V2:
- The device was running V1 and should be migrated to V2.
- The device hasn't run yet, and has been programmed with V2 out of the factory.

The migration manager should store the last version somewhere, so it can use that to figure out what migrations to run.
Now, my question is, where do I store the version of the last migration?
My first idea was to store this in settings, but what if that changes in the future, like the example above?

[MicroController]

I'd say store the current version of whatever you may want to migrate later with that entity. In case of configuration, include a meta-data "version" configuration field in the configuration.
The cohesion in this case seems desirable.

[vanBassum]

I get what you're saying, but that would create a problem of itself:
Let's assume:
V1 stores the settings in NVS
V2 stores the settings in JSON

After boot, we don't know the previous version, It could be V1 or V2. In order to check what the previous version was, I need to read the settings. But I can't read the settings, since I don't know whether to read from NVS or JSON.

For this particular case, I could try to read both NVS and JSON. One of them would fail, and the other would contain the version. But I don't know if this would always be the case.

[MicroController]

I see your point.
I think it should still be safe to store the version number with the configuration. The migration would then retrieve the version number of e.g. nvs and of the JSON. Either or both could a) fail (->doesn't exist) or b) yield a version number, in which case the latest version number is the current/active one.

Of course, it may be more simple to just store the current version number in a "well-known" place that's always available, i.e. nvs.