Rudder plugins

https://github.com/Normation/rudder-plugins/pull/147 bring the question of plugin versionning rules. Until today, we only had simple cases, and things were working ok.

So, when we started with the versionning scheme, the plan was "follow Rudder rules", ie:

- bug fixes in the oldest maintained branch, with a A.B-X.Y.(z+1) release,
- new feature in the latest branch.

As maintained branch was expected to be short term and feature in current branch, it could have work. It's clearly not what is happening.

So, clearly that does not work, and will even less work with the multiplication of plugins and Rudder branches supported, so we need to adapt our scheme.

To start with the problem, what are the desirable properties for the plugin versionning rules?

I see:

- from an user point of view, it is easy to map a version to a set of feature,
- for a user, it is easy to know in what version a bug is corrected,
- feature can be added in any rudder branch,
- bug can be corrected in oldest branch,
- we are able to have different feature set (ie major version) of a plugin for different or the same rudder branch.

Given that, I think there's only two scheme that could fly:

- 1/ a plugin has exactly the same version in all rudder branch, with the same bug fixes and features.
- 2/ a plugin has a version starting to 1.0 on each branch.

1/ allows people to clearly understand what "Datasources 1.5" is, and build a clear expectation from the number (which is also desirable from a licensing perspective, because the message is that the license is for a plugin version, not a plugin+rudder version). It minimizes surprise regarding bug correction and version, and make it simple for us to make release note (one release note for a version of the plugin on all branches).
On the other hand, it means that some branches will have new version with zero changes (for ex if a bug is due to a problem with a given branch of rudder only) and we still can have divergence (for ex if a feature is only possible in latest branch of Rudder because it's the only one providing the infrastructure to get it). The former point does not seems blocking, and the latter point means that in such a case, we will need a bump of the major version number of the plugin (and so, perhaps maintain several major branches of the plugin, which is not possible

2/ Allows to have totally different release speed with different feature set and bug corrections in each rudder branch. With it, it is possible to choose to bump major version of the plugin in one branch (even an older one) without doing so in an other. We can also have feature in only one branch, even an older one (I think for example to some workaround option that only need to appear in an older branch).
On the other hand, with it, "datasource 4.3-1.0" and "datasource-5.2-1.0" are totally different plugins, the first being the first ever version of datasource, full of bugs and with a limited feature set, the second being a mature, production-tested version of datasource with a rich feature set. We also need one changelog by branch by plugin version (because for real, the plugin version is the whole thing, Rudder branch included, and not the last part only).

So, what do you think people? What is the more desirable feature ? Do you see other numbering scheme ?