Developer forums (C::B DEVELOPMENT STRICTLY!) > Development

SDK Versioning sceme, plugin sdk version check

(1/2) > >>

i would like to add a new function to the sdk, this means increasing the sdk version.
I have found some problems i  would like to discuss.

I think we should (and i think we are using) use semantic versioning scheme:

According to my understanding we have "shiftet" the scheme by one and are not using the "patch" number.:
PLUGIN_SDK_VERSION_MINOR  -> patch version  (internal changes, probably behaviour changes)
PLUGIN_SDK_VERSION_MAJOR  -> minor version (adding functions)
PLUGIN_SDK_VERSION_RELEASE -> major version (removing functions, non backwards compatible interface changes)

So adding new features should be covered by incrementing the PLUGIN_SDK_VERSION_MAJOR. This should allow all plugins to still be usable without recompiling.

Our current implementation does not allow me to change any version number and still use old compiled plugins.
The check is performed in pluginmanager.cpp:700

--- Code: ---if (major != PLUGIN_SDK_VERSION_MAJOR ||
        minor != PLUGIN_SDK_VERSION_MINOR ||
        release != PLUGIN_SDK_VERSION_RELEASE)
        // wrong version: in this case, inform the user...
        wxString fmt;
        fmt.Printf(_("SDK version mismatch for %s (%d.%d.%d). Expecting %d.%d.%d"),

--- End code ---
I think this is wrong and the PLUGIN_SDK_VERSION_MINOR and PLUGIN_SDK_VERSION_MAJOR check should be a ">" check. So if we add functions old plugins should still be working without problems.
Removing functions or changing the interface of functions should result in increase of the major version. Here we can perform an = check because no backwards compatibility

any comments?

seems reasonable to me. If we don't foresee any regressions, might be the way forward.

My 2c of feedback is:

1) Looks like a good change.
2) The WIKI documentation and the code will need to have info in them to ensure (okay try) people follow the semantic versioning as it's been like this for a very long time.
3) Be aware that most of the plugin's manifest.xml file are very old and specify the release as 1. With all of the changes over the years this may not be correct. These could be bumped in the same change or left for later.

Looking at this notes:
The recommend to increase the PLUGIN_SDK_VERSION_RELEASE  number only after public releases or else the numbers could get quite large. Public releasases are quite rare for us, but we have a lot nightly builds and this leads to the same problem as now. If we do not increase the PLUGIN_SDK_VERSION_RELEASE  version on every change the nightly releases can still not be used correctly with old plugins. I think this is some point. Do we mind if we get PLUGIN_SDK_VERSION_RELEASE  in the 100s range?

This afternoon I jot clobbered on the Mac with the version check change failing (plugin 2.16.0 and CB SDK 2.19.0 btw).. I have no idea why the plugin loaded on Windows without triggering the failure.
If you look at the some of the version number of MS DLL's that are to do with the MSVC the last octect of the version number jumps 100's between releases in allot of cases.

BTW I changed the check to the following as it makes more sense and resolved the issue I had:

--- Code: ---    if (    major > PLUGIN_SDK_VERSION_MAJOR ||
                major == PLUGIN_SDK_VERSION_MAJOR &&
                minor > PLUGIN_SDK_VERSION_MINOR
            ) ||
                major == PLUGIN_SDK_VERSION_MAJOR &&
                minor == PLUGIN_SDK_VERSION_MINOR &&
                release > PLUGIN_SDK_VERSION_RELEASE

--- End code ---


[0] Message Index

[#] Next page

Go to full version