Personal Blogs

People frequently ask the question 'when will [an OU-developed Moodle plugin] be available for [a new or upcoming Moodle version]?' So I'm writing a blog post to cover it. Not very amusing I'm afraid...

In general, OU releases are about six months behind the community Moodle version (possibly seven months now the community schedule has been shifted). This is necessary to ensure reliability but also to give us time to update our plugins, while maintaining new feature development.

If you want to use a released, tested version of our plugins, you'll need to follow our release schedule. Or if you want to live life on the edge, you should probably find that the untested 'master' branch of our plugins will have been updated to work on the next Moodle version by about two months before our live release, i.e. about four months behind moodle.org.

This was probably hard to understand, so let me do headings and bullet points.

If you want a Moodle 2.4 version of our plugins...

• (Moodle 2.4 came out on 3 December 2012.)
• An untested version has been available in the 'master' branch of each plugin in GitHub since approximately the start of April 2013.
• The tested version will be available in the MOODLE_24_STABLE branch of each plugin in GitHub at some point early in June 2013. (You can pester me online if I have forgotten to update it!)

If you want a Moodle 2.5 version of our plugins...

• (Moodle 2.5 came out on 14 May 2013.)
• An untested version will be available in the 'master' branch of each plugin in GitHub by approximately the start of October 2013.
• The tested version will be available in the MOODLE_25_STABLE branch of each plugin in GitHub at some point early in December 2013.

Caveats

• The above dates for our future releases are not definite and are subject to change!
• You can extrapolate from this to Moodle 2.6 (June 2014 live date), Moodle 2.7 (December 2014), etc - although we might change our release pattern by then, who knows.
• As soon as we release a new stable version, we stop supporting the previous stable version. For example, once we have a MOODLE_24_STABLE branch, there will be no more changes to our MOODLE_23_STABLE branch. If anybody wants to support these old branches, we suggest forking our GitHub repositories.

Occasionally asked questions

• I want to use your plugin in a new Moodle version before these dates, does it work? No idea! Please try it. (Sometimes plugins intended for a particular Moodle version will actually work unmodified in the next version. Unfortunately there are lots of cases where this does not hold true.) If it doesn't work, you can feel free to file a GitHub issue, but we probably won't fix it sooner than those dates.

• It doesn't work but I still want to use it before these dates, what can I do? Please fix it yourself and send us the patch.

• I have a patch that fixes your plugin for the next Moodle version, do you want it? Yes we do! And thank you for fixing it. But because of how our release process works, the 'master' branch of our plugins has to refer to the release currently in development at the OU. For example, if you submit a patch now for Moodle 2.5, we won't be able to put it on the master version of the plugin until about the start of September 2013 (about a month earlier than the dates I gave above). Of course, if you've put your patch on a GitHub issue, then other users can still benefit from the patch sooner by applying it manually themselves.

Oh dear, it's my first blog post of the year.

There is probably something more interesting I could talk about, but we're getting a bunch of questions about 2.4 versions of OU plugins lately.

To recap the OU schedule:

• We typically go live with a Moodle release about six months after it comes out, unless something goes wrong.
• Development for our release takes a three-month period that ends about a month before our release.

In this particular case for 2.4:

• We should have stable versions of our plugins for 2.4 (MOODLE_24_STABLE) in June.
• We should have development versions (on the master branch) that work in 2.4 at some point between February (yes, I know it's February now) and the end of April.

Of course, some of our plugins from previous releases may continue to work unchanged - it depends whether any of the APIs in Moodle core were modified in a way that breaks our plugins in that release.

Where our plugins don't work in 2.4, feel free to file an issue on our GitHub site, but be aware that we won't fix it until our development period starts. If it's a simple problem and you want to fix it for us by submitting a patch, please do - we'll try to apply these patches early in the development period, i.e. more like February than April. (We can't apply them before the development period starts though, sorry.)

This is a special super bonus blog post. Not only are there two blog posts in one day, but this second one has two screencasts in it!

In today's Moodle developer meeting, I suggested (rather rudely, sorry) that the OU's subpage module was a better way to handle the 'everything in Moodle course has to go on the same single page which is stupid' problem than implementing some kind of 'show things on separate pages' feature in every single course format.

Subpage - quick demonstration of subpage using the standard theme so it looks pretty much like standard Moodle (about 5 minutes)

Subpage in real life - how we use subpage at the OU (about 3 minutes) - you get to see our pretty theme in this one

Here are some reasons I think subpage is a good approach:

• Not dependent on course formats, or inconsistent depending on which format you're using.
• Obvious; easily understandable by students and staff. (Except the name! The name sucks, but I couldn't think of a better one.)
• You can keep using convenient views that take advantage of the course format to see the entire structure of the course at once (only it won't be ridiculously long now), or to show N weeks around current, or whatever it is.
• Generally more flexible - for instance, want to nest pages within pages? With subpage, you can. (It's probably a bad idea, though!)

There are some problems with the way subpage is implemented; basically, it's a leetle bit of a hack. In order to make it un-hacky, some of the following things would need to happen to core:

• Add all the 'come back to this URL afterward' features that we included in a short patch.  Without that, in core Moodle every time you do anything in a subpage you end up back at the course page. (For instance, add a forum? Okay, great, but after it's added you're back on the course page.) It isn't really practical to use without this patch even though it does basically work if you struggle through.
• Implement something (ownercmid?) in the sections table to indicate that they're owned by a module and therefore take them out of the ordinary numbering. Apply some changes to backup and restore and navigation and formats to make this slicker. (It works OK without, we're using it, but we do have a few special things in our course format to handle it as well...)
  Note that this change would let authors create other modules that can include sections/Moodle activities, which could actually be pretty cool.

Subpage code repo (...may or may not work at the moment, I hope it does though).