Question #13946
closed
Plugin versionning rules
Description
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 ?
Updated by François ARMAND about 6 years ago
In fact, it's even more complicated than that. Because a plugin can be compatible only with some range of Rudder due to binary changes. We try to minimize these one and we are setting up processes/rules in that goal, but binary compat happens, and in that case, what are the rule we follow? What happen for an user who is locked in one Rudder version forever (say, 4.3.8), and a binary break happen afterward? In case of the rule scheme 2/, do we reset versionning so that 4.3-1.5 is the last available, and then with have 4.3.8-1.0 and 4.3.9-1.0, etc ? (it's the underlying reallity, but for a user, it's a nightmare)
Updated by Vincent MEMBRÉ about 6 years ago
Been thinking for a long time.
The thing is we never had Z releases, only Y even if only bugfixes. So it's already a change to me, to add Z versions to plugins. In fact there would imply really less Y version update making it easier to think. But also a Z release may be binary incompatible with the Z-1 version ...
I think we should not manage it in the version of the plugin, so i won't go for 1/
I think Rudder support version should be managed at the level of rpkg/plugin metadata, like we declare dependencies in metadata and they are checked at plugin install, so if the plugin is being installed on an invalid version, it breaks
Also we should have better documentation and better repository organisation to reflect this(maybe a directory for each minor version of rudder containing valid plugins) ,
Idea 2/, Starting from version 1.0 for every version of Rudder, is way too much complicated for our users and they won't understand it
An idea, would be to simplify plugin versionning, Just being X.Y.Z and having no reference to Rudder, In fact i think of X should change at every version of Rudder (let's say if it's 5.0 compatible, we have 1.y.z versions and for 5.1 we have 2.y.z) and maybe upgrading Y if there is a change of Rudder minor version to build the plugin (ie 1.4.z of datasource could be built with 4.3.5, and 1.5.z could be built with 4.3.8 ) but also for feature change ? , leaving z as the only bugfix release ? (or also feature update ?)
My prefered idea in fact is: adding -z support to current versionning but change the way we manage version of the plugin, with something like previous proposition ( Rudder major is already handled by first part, X should manage a change of binary version, Y a feature change, and Z a bugfix only ...
Updated by Nicolas CHARLES almost 6 years ago
- what we expose to user
- what we do internally
It is much easier (as you said) for user if we have only one version of plugin (X.Y) - independently of the Rudder version
In real world, there's a clear dependency between Rudder and plugins (some plugins may require a minimal version of Rudder A.B.C, and fail on a max version Rudder A'.B'.C')
So from the user point of view, we need a facility to get the plugins only compatible with current Rudder installation - a webservice, a public API, or knowledge embedeed in rpkg + rudder itself (last one sounds quite hard)
Updated by Alexis Mousset about 1 year ago
- Status changed from Discussion to Resolved
- Regression set to No
this has been decided since.