# Add the plugin version checks
**URL:** https://discourse.kitware.com/t/add-the-plugin-version-checks/345
**Category:** Using SMTK
**Created:** [November 14, 2019, 8:36pm UTC](https://discourse.kitware.com/t/add-the-plugin-version-checks/345 "2019-11-14T20:36:05Z")
**Posts on this page:** 7
**Page:** 1
### Author:  [@Haocheng\_Liu](https://discourse.kitware.com/u/Haocheng_Liu)
#### Post date: [November 14, 2019, 8:36pm UTC](https://discourse.kitware.com/t/add-the-plugin-version-checks/345/1 "2019-11-14T20:36:05Z")
Recently when developing smtk plugins, I spent hours to debug a mysterious bug and it turns out that it’s just because my custom plugin is linking against smtk 3.3.0, but my CMB is linking again 3.2.0. Thus the new feature is never triggered.
# Suggestions
- If the custom plugins are linking against version A while model builder is linking against smtk version B, it should error out. We could make the version to be a static string/ int for comparison purpose.
- For smtk plugins, plugins with different linkages should are detected and warned.
When designing the versioning in smtk, we have left many rooms and spaces for utilization and improvement. Now it’s a good time to explore them. Thoughts and Ideas?
---
### Author:  [@tj.corona](https://discourse.kitware.com/u/tj.corona)
#### Post date: [November 14, 2019, 8:48pm UTC](https://discourse.kitware.com/t/add-the-plugin-version-checks/345/2 "2019-11-14T20:48:24Z")
We currently have a class `smtk::common::Version` automatically generated from CMake variables (you can find it in your build directory). We could use this class at compile time to imprint versions (we may have to make them `constexpr`, as this was written pre-c++11) in our plugins and compare against the runtime-evaluated versions in a plugin’s registration code. What do you think?
---
### Author:  [@dcthomp](https://discourse.kitware.com/u/dcthomp)
#### Post date: [November 14, 2019, 8:51pm UTC](https://discourse.kitware.com/t/add-the-plugin-version-checks/345/3 "2019-11-14T20:51:04Z")
That would be good for modelbuilder (which could use the SMTK version it is provided) but would not do anything for ParaView. Should we also try to detect when different plugins use different versions of SMTK? That might potentially catch even more problems.
---
### Author:  [@tj.corona](https://discourse.kitware.com/u/tj.corona)
#### Post date: [November 14, 2019, 8:52pm UTC](https://discourse.kitware.com/t/add-the-plugin-version-checks/345/4 "2019-11-14T20:52:34Z")
The singleton `smtk::extension::paraview::PluginManager` could do that.
---
### Author:  [@Haocheng\_Liu](https://discourse.kitware.com/u/Haocheng_Liu)
#### Post date: [November 14, 2019, 9:00pm UTC](https://discourse.kitware.com/t/add-the-plugin-version-checks/345/5 "2019-11-14T21:00:35Z")
LGTM. My understanding is that we require all plugins to be built with the same version of smtk so the registration code only needs to check if the version matches.
In order to imprint versions for each plugin, does the plugins now have its own version class or just a constexpr string/int?
---
### Author:  [@dcthomp](https://discourse.kitware.com/u/dcthomp)
#### Post date: [November 14, 2019, 9:07pm UTC](https://discourse.kitware.com/t/add-the-plugin-version-checks/345/6 "2019-11-14T21:07:56Z")
I think the idea is that `PluginClient` or `PluginClientBase` would include version numbers. When the `PluginManager` registers a plugin, it could warn or error if the version numbers in the client do not match what it has already registered (if any).
If you want to get fancy, you can make the PluginManager do different things depending on differences in the major/minor/patch version numbers. For instance, a PluginClient might indicate that it does not care about minor version mismatches. I would not attempt this in the first pass.
---
### Author:  [@ben.boeckel](https://discourse.kitware.com/u/ben.boeckel)
#### Post date: [November 14, 2019, 11:49pm UTC](https://discourse.kitware.com/t/add-the-plugin-version-checks/345/7 "2019-11-14T23:49:28Z")
Does this mean we’re updating the version number on every incompatible change? Every feature addition?
With shared libraries, you’ve lost if there are incompatibilities as soon as you `dlopen` the library. It could have brought in some incompatible SMTK and there’s no reliable way to evict it (static initializers being what they are).
One possible canary solution would be to embed the version information into the symbol that is generated and looked for by the plugin loading mechanism. For example, instead of `some_static_function` lookup, you lookup `some_static_prefix_${versioninfo}`.