Contributed plugins versioning
Moodle core itself has a solid versioning scheme (see the documentation page describing it). However, authors of contributed plugins are pretty free to use their own system of versions numbering. As the author of some contributed plugins, I was looking for a good versioning scheme for my contributions. From my point of view, such a “good” solution should (1) be stable in the long-term period and (2) intuitively describe the required Moodle core version the version of the plugin is for.
After considering several alternatives, I ended with a system similar to the one used by the Moodle core itself. So I use versions consisting of three numbers separated by dots, for example “2.1.3″. The first two of these numbers declare the Moodle branch the plugin is intended for. So the plugin with the version 2.1.3 would be for Moodle 2.1.x. The last number is the sequential update number. And of course, the plugin with the version 2.1.3 would be the fourth update of the plugin as all real geeks who were breast-fed by C like languages start counting with zero (2.1.0 was the initial release of the plugin).
This scheme fits well the convention of using standard Moodle names for development branches in Git. The repositories of my contrib plugins have branches MOODLE_21_STABLE etc like the Moodle core has. So the plugin version 2.1.3 would be born on MOODLE_21_STABLE branch in its repository. Naturally, I use Git tags for the version releases points. Luckily there was no need to re-invent anything here as together with the switch from CVS to Git, Moodle started using standard tags like v2.1.3 instead of legacy MOODLE_213 style.
Just today, I realized this approach has yet another aspect I did not fully realize initially. It forces the plugin maintainer to release new plugin version together with the Moodle major release. Even if there is no real update of the plugin. As an example, the Course contents block is pretty feature complete and there are no known bugs in it (ok, that’s a bit of blaspheming). The most recent version of it was 2.1.2. Now when Moodle 2.2 is released, I had to go and release 2.2.0 of the block to follow my guidelines. Even when the code of the block has not changed.
Is it a disadvantage of this scheme? I believe it’s not. It’s actually a great opportunity to confirm that the plugin still works on the most recent Moodle version. And also it’s the information for the users that the plugin is still actively maintained. Even by releasing the new version for purely formal reasons, I as the maintainer declare publicly that I tested the current version of the block with Moodle 2.2 and consider it stable and working. And that is worth going through the whole release procedure – branching, tagging and uploading the new version to the plugins directory.
