Hi all,
does anyone know if there exist moodle best practices for plugin versioning?
I thought it could be nice to have a versioning method which somehow relates to the moodle version the plugin wokrks with and at the same time indicates it's own development progress...
Hope it's clear what I mean
Flotter
I'm not sure if relating to the Moodle version is a good idea but I use a simple major/point number approach. So at the moment I am on 1.4 and I have a 1.5 beta cooking which I am meaning to release in the future. I'm not quite sure how big a change I would consider a jump to version 2.
I am with Marcus. Trying to make your version numbers correspond to Moodle version numbers seems appealing at first, but there are too many things that might force them out of sync, and they you are left with version numbers that look a bit like Moodle version nubmers, but actually don't match.
So, I now number my plugin releases v1.0, v1.1, ... Those are the tag names I use in git. If I need different versions of my plugin to work with different Moodle branches, I will make tags like v1.1_m21, v1.1_m22
Then, in the version.php file, I put a fuller description like
$plugin->release = '1.3 for Moodle 2.5+';
I think for end-users it's clearer for plugins to have the same major version number as the Moodle versions. And that's what I do with the plugins I maintain.
Of course it's not perfect, since this may look as follows:
| moodle versions | myplugin versions |
| 2.6.0 | 2.6.0 |
| 2.6.1 | 2.6.1, 2.6.2 |
| 2.6.2 | 2.6.3, 2.6.4 etc |
| ... | |
| 2.7.0 | 2.7.0 |
| 2.7.1 | 2.7.0 |
Most plugins I have seem to maintain a git branch for each major version of Moodle they support.
As for the version number on the master branch it should generally use the day code for the changes, other branches should only update the last two digits (so you don't end up in a situation where say a Moodle 2.6 version of the plugin has a higher version number than a 2.7 version)
i.e. See what Moodle does here: http://docs.moodle.org/dev/Moodle_versions
Neill "... (so you don't end up in a situation where say a Moodle 2.6 version of the plugin has a higher version number than a 2.7 version)"
That happened to me once and it caused quite a few problems. Well, I learnt a lesson.
Joseph
Note that the "plugin version" may be a bit confusing as it may refer either to the $plugin->version number (some call it build number) or the $plugin->release information. There are quite strict rules recommendations on $plugin->version - see e.g. https://moodle.org/mod/forum/discuss.php?d=256943#p1114287
The $plugin->release is the information for human users. It may be almost anything, not even necessarily numbers.
Hi all,
thanks for all the interesting replies!
When talking about "versioning" I mean that which every developer can choose freely and not the $plugin->version number (which is contructed out of year, month etc.)
For moodle itself this versioning is very clear and consistent. But let's think of a moodle administrator who has to manage several moodle instances where each has installed different extearnally maintained plugins, this can become confusing for this person.
From this perspective I think the approaches of Tim and Joseph are most suitable but maybe could be improved (and then even standardized).
Tim wrote:
"So, I now number my plugin releases v1.0, v1.1, ... Those are the tag names I use in git. If I need different versions of my plugin to work with different Moodle branches, I will make tags like v1.1_m21, v1.1_m22
Then, in the version.php file, I put a fuller description like
$plugin->release = '1.3 for Moodle 2.5+'; "I think it's clear but why to use different methods in your tags and in $plugin->release ?
Joseph wrote:
I think for end-users it's clearer for plugins to have the same major version number as the Moodle versions. (...)
| moodle versions | myplugin versions |
| 2.6.0 | 2.6.0 |
| 2.6.1 | 2.6.1, 2.6.2 |
| 2.6.2 | 2.6.3, 2.6.4 etc |
| ... | |
| 2.7.0 | 2.7.0 |
| 2.7.1 | 2.7.0 |
I think it is clear for which version but might be confusing as plugin and moodle versions look the same.
How about this:
2.7-1.3
The first two digests indicate the moodle version. Then foolows a "-" and then then the version which indicates the development progress of the plugin related which is compatible to the related moodle version.
Example:
There is a plugin which works fine with moodle 2.6.1 - 2.7.0, then the versioning would look as follows:
| Moodle version |
Plugin version (original way) |
Plugin version (improved way) |
|---|---|---|
| 2.6.1 | 1.4 | 2.6-1.4 |
| 2.6.2 |
1.4 | 2.6-1.4 |
| 2.7.0 |
1.4 | 2.7-1.4 |
I know , old thread and so on. But I just want to put my two cents...
I just use semantic versioning for my plugins (release description and tags in git) and try to keep compatibility for the last three moodle versions with the current plugin version.
eg. if the current version of my plugin is 1.6 it might be compatible at least with moodle 3.0, 2.9 and 2.8. Possible also with older moodle versions (2.7, 2.6, ...).
If my plugin needs some changes to work with moodle 3.1 I try to not break compatibility with the previously supported version. If not possible, again, I try to keep compatibility at least to the last three versions. This should normally possible due to deprecated moodle functions were kept for at least three versions before they are removed. When breaking with compatibility to a previously supported version I raise the major version number (--> api incompatibility). eg. plugin version 2.0 supports moodle 3.1, 3.0 and 2.9.
The actual version YYYYMMDDXX is changed as follows: Patch part (XX) will increased when releasing patch or minor versions, the date part will adopted when releasing a major version.
Additional the README file contains a list of supported moodle versions for the particular plugin version.
