Version number breakdown

Re: Version number breakdown

by David Mudrák -
Number of replies: 0
Picture of Core developers Picture of Documentation writers Picture of Moodle HQ Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers Picture of Plugins guardians Picture of Testers Picture of Translators

Its primary purpose is to enable multiple branches of the plugin, as Davo noted. Some add-on maintainers follow the Moodle core's development model and they have branches like master, MOODLE_26_STABLE, MOODLE_25_STABLE etc in their add-on. Imagine there is a plugin FooBar version 5.0 released for Moodle 2.5.x series, and also FooBar version 6.0 for Moodle 2.6.x series (the maintainer of the plugin has them on separate branches). Let us say that there was some fix needed in a code specific to the 5.0 version so the maintainer wants to release the version 5.1 of the plugin (for Moodle 2.5.x).

The problem is, the plugin's version must never get "disordered". That means, the version number of 5.0 must be always lower than 6.0. But also, any (future) 5.x version of the plugin must be lower than any 6.x version.

If the maintainer did a mistake and had, for example

$plugin->version = 2014010100;  // For the plugin release 5.0
$plugin->version = 2014010101;  // For the plugin release 6.0

and then in the new release 5.1 would do something like

$plugin->version = 2014032400;  // For the plugin release 5.1

then poor users will not be able to upgrade the plugin from 5.1 to 6.0 (as Moodle would consider it as a downgrade from 2014032400 to 2014010101).

The solution is to do what Moodle core does. Freeze the date-part of the version number once a new stable branch of the plugin is released and use the "xx" as the incremental counter for the updates on that branch. So the correct situation would look like this:

$plugin->version = 2014010100;  // 5.0
$plugin->version = 2014010200;  // 6.0
$plugin->version = 2014010101;  // 5.1

If you do not use multiple stable branches in your plugin and all the releases are made off a single (master) branch in a linear way, then using the date of the release will guarantee the upgrade doable, of course.

Just a side note, the Moodle core uses decimal numbers in the main version so it has more than 100 ugrade steps available on stable branches. Plugins still has this limit, but it is not a big deal. If 100 upgrade steps is not enough for a single plugin, one should not consider that branch "stable" anyway wink

Average of ratings: Useful (3)