Locking the major version number of plugins to the major version number of pymodaq core: plugin 5.y.z should be compatible with pymodaq 5.w.x

[quantumm]

Hi everyone,

I have a suggestion regarding the version numbering of the plugins. Currently the version number of a plugin does not make much sense and it is difficult to grasp at first sight which version of a plugin is compatible with which version of pymodaq core. This creates compatibility problems mainly issued when a major version of pymodaq core is released (by major release I mean when we go from pymodaq 4.w.x to 5.y.z for instance).

I think an easy convention would be to lock the major version number of a plugin to the major version number of pymodaq. For instance, pymodaq_plugins_smaract 4.1.3 would be compatible with pymodaq 4.3.6. I think this would increase the visibility of which plugin version is compatible with which pymodaq version. For the end user, just by looking at the content of his python environment with a mamba list command, he could directly see if there is an obvious compatibility problem.

This locking should be kept only to the major version number because it makes no sense that a new pymodaq feature or bug fix (indicated respectively by minor and patch numbers) should be related to a new feature or bug fix of a plugin. Also, it should be kept in mind that an end user does not necessarily use the last version of pymodaq, and may not want to use the latest version. In this scenario, it is possible that some new features and bug fixes would be implemented to a plugin compatible with an old version of pymodaq. In this case the plugin maintainer would increment the minor and fix numbers of the plugin that are still free to evolve.

[quantumm]

This would imply that a new branch is created for each plugin when a new major version of pymodaq is released.

[quantumm]

Also a plugin maintainer could then keep the dependency requirement to a strict pymodaq == 4.x.y rather than pymodaq > 4.x.y

[seb5g]

I like it and already use this with pymodaq_data and gui. I think also it makes things clearer.

[seb5g]

@aurore-finco maybe an idea of discussion at the pymodaq days (maybe...)