An awkward issue has arisen which is now blocking GPII-3119 - that work introduces a backwards-incompatible change to the format of the solutions registry as dispatched in the "solutionsRegistryEntries" matchmaker output, eventially sent to the SPI settings handler on the client. We have a number of clients deployed in the wild which will fail if sent such entries.
Before we can merge GPII-3119, we need to implement the following:
i) Every keyin request sent by the client needs to include a version field indicating the solutions registry format it is prepared to accept. If this field is missing, the value will default to "1" indicating the current, now legacy format
ii) The solutions registry files, e.g. win32.json5, will have to be accompanied by a metadata.json5 file (in the same dir will do) which indicates what their current format version is.
iii) The cloud on receiving this version field, before it dispatches solutionsRegistryEntries to the client, will work through a series of transforms which are registered in it which will transform them to whatever historical format is expected by the client.
This work correlates with GPII-4273 which should be finished first. This ensures that versions of the solutions registry which are downloaded by clients for their own use correlate with their own version.
It also anticipates work on the Live Solutions Registry by Tony Atkins for GPII-4125.