With this proposal, I suggest to introduce rules for the version numbering of the AddInInterface.
This version number can be found at the bottom of the document addInInterface.h.
The version number is incremented in an unspecified way once a binary-incompatible change (see https://community.kde.org/Policies/Binary_Compatibility_Issues_With_C%2B%2B) is done to any library, that is part of the itom SDK. If itom loads a plugin or designerPlugin, it compares the addInInterface version number of this plugin with the addInInterface number of itom itself. If they are equal, the plugin is loaded, else it is refused.
I propose to use the rule of semantic versioning (https://semver.org/) for the interface version number. Hence:
- The patch is incremented, if any kind of bugfixes are done without changing any part of any exported libraries, that are part of the SDK of itom.
- The minor number has to be incremented, if anything is added in a backward compatible manor to any library of the SDK. Backward compatible means, that the binary compatibility is still given.
- The major number has to be incremented, if anything is changed, added or removed, that breaks the binary compatibility of the SDK.
If this pattern is introduced, itom can insert a more relaxed scheme for accepting plugin or designer plugin libraries:
- For any interface <= the current interface number 3.2.0: The old rule holds and the exact, full version number must be equal
- For an interface number > 3.2.0: itom accepts plugins, implementing the same major number, a minor number that is smaller or equal than the number of itom and any kind of patch number. Example: