Hey there,
I am looking for some background information on the thoughts behind the different forms of validation-set versioning. As far as I understand there are 3 identifiers: name, sequence nr and revision. When should we update which identifier?
Normally we adhere to semantic versioning (major.minor.patch), is this somehow mappable to the validation-set versioning? How would you map them?
A bit of background of what I am trying to achieve:
- We are developing snaps for an Ubuntu Core device that is updateable in the field
- We want the devices in the field to only have specific combinations revisions of snaps (that are validated in unison)
- We want to be able to strictly version these combinations of snaps
- One version should always have the exact same combination of snaps + revisions
- We want to be able to easily retrieve what version a particular device is on
- If we do an update and a snap fails to install, we want all snaps to roll back, so the device is still on a validated combination of snaps + revisions
Question 1: From what I understand we cannot pin a device to a validation-set on a particular validation-set revision, but only to a sequence number. This leads me to conclude that to achieve all the above points, we should completely ignore validation-set revisions, and make a new sequence every time.
Question 2: Does it make sense to have different validation-set names between major releases of our firmware set? Sort of how channels are done on snaps? Will the transition and fallback logic be the same going from validation-set1=1 to validation-set1=2 be the same as moving from validation-set1=1 to validation-set2=1?
Do you have any other insights or tips on how other people do iot-device versioning? Is it possible to get into contact with whoever designed validation-sets to figure out the original thinking and intended use cases?
Kind regards, Charlee