We want to keep it this way so people can still make plugins work for older versions of Cura, like 3.6, where the 'api' field with just a single major version, instead of the 'supported_sdk_versions', which can be either a version-string like '7.6.0' or a list of version strings.
The Cura 4.9 release will have expanded functionality. If you have a plug-in that uses this functionality, marking it as using SDK 7.5.0 will notify older Cura releases that they can't use that plug-in.
The one actual change was this: To give a KeyError when stuff can't be found in a dictionary, rather than returning None there and then getting a TypeError later.
Contributes to issue CURA-5936.
I'm not really awake today, am I? The functionality happened to still work because of how our real data is structured right now, but the tests still failed. Those are successful now.
Contributes to issue CURA-3427.
Just a mistake that I saw because my IDE warned me about this. If a variant in Cura 2.3 has no general/name keyword, then it would break here. Now it doesn't break any more and gives a nonsensical name.
Contributes to issue CURA-3427.
We now have a (format) version and a setting version. Ideally we'd like major-minor version numbers in our profiles. However, introducing major-minor version numbers requires substantial changes to the version upgrade manager to compare version numbers, find a path towards the current version, or even keeping track of the current version. Therefore we just collapse the two version numbers into one: Multiply the major version number by a million and you'll never exceed it in the minor versioning. The only problem is that we now have to update the versioning for all of our three upgrade plug-ins, because they all need to know locally how to find the version number of their file types (because the upgrade manager has no knowledge of the file types) and they have no access to each other because a plug-in may be disabled.
Contributes to issue CURA-3427.
