How often do you upgrade your Moodle™?
According to Moodle™’s official stats, about a third of all registered sites run the latest version, 3 months after its release. While nearly half already runs a version less than a year old —or a Long Term Support (LTS) release— that leaves a sizable chunk of sites running an older version of Moodle. It can be concerning to think there’s a few thousand sites running a version of the LMS that no longer receives security updates.
Broadly speaking, it seems most Moodle admins do not upgrade Moodle right away, and the average delay is around 1 year. Two contrasting questions come into mind: What can be done to shorten the delay to upgrade an LMS? And, is a twice-yearly release schedule really worthwhile or necessary?
There is hardly a consensus among the community, but plenty of insight has come up among. Former Moodle™ Users Association Chair Steve Powell weighed in a while back. Part of a team managing Lancaster University’s LMS he explains how they are comfortable with a spring-only update:
«It may seem that there would be plenty of time between May and September to upgrade, but in practice this is not the case. There are a lot of modifications/plugins that we need to refactor and test, and that takes time. We try and get a test version of the new release out there for staff to see by June/July, but this puts a lot of pressure on developers and carries some risk. We try and get a test version ready and publicly available to staff as early as we can because we know that the majority of academic staff are away from July on. We put out lots of comms through different media every year, but we know that an awful lot of teaching staff will only see the new version of the VLE in September when they come back to teach. So just before teaching begins, when academics and support staff are already overloaded with work and under stress, the upgrade creates additional issues to deal with.»
From Coventry University, near Birmingham, Jeremy Hopkins also skips a version, but follows the November-December releases, which he deems “more stable.” In California, Carl Thelen upgrades to the latest point version over Christmas, with minor upgrade during the summer break, to give teachers a more comfortable chance to get acquainted with radical new features or UI changes.
Other examples differ only slightly. Sites that upgrade to the major version every six months are rare occurrences.
Plugins and Users: Does Moodle™ upgrade too much?
The decision to upgrade depends heavily on the complexity of the site, in which plugins and customizations usually play a significant role. Admins make tradeoffs. New Yorker David Pesce seems to err on the site of simple, up-to-date sites:
«I’ve found that decreasing plugins and/or dedicating time to upgrading critical plugins to be compatible ends up decreasing the amount of time for testing. We definitely can’t do this on every instance we manage (because of core modifications, ancient plugins/themes, etc.), but on the ones we can, testing is greatly simplified. I’d wager to bet that the time spent upgrading the critical plugins is less than the time it took for testing.»
Other factors playing into the scheduling decisions include the scale of the size, and the number of sites under the control of a single admin. Dutch Moodler Gemma Lesterhuis manages “20+” Moodle™ sites by herself. In these kind of extreme scenarios, LTS Moodle™ come in handy, especially as it is often difficult to evaluate the benefits and costs of a new release series.
When the user side of things comes up, it almost unanimously supports the once-per-year rate, in some cases reluctantly. While there are usually a small and vocal squad of early adopters in every organization, the vast majority prefers as little change, delayed as much as possible. Michael Hughes from Glasgow explains it best, when replying if whether Moodlers prefer copious or sparing upgrade schedules:
«As a Moodle™ developer and admin, yes. We’re well on board with future changes and the roadmap. For the majority of our teaching staff, however, [the answer to a semiannual upgrade schedule is] categorically “No.” Not going to in to the rights or wrongs of why they don’t or can’t, because ideally they would. There is also definitely a group who would prefer that it never changed at all.»
Should Moodle™ change its release schedule?
Samson proposes an April and October schedule. That is, making releases available one month earlier than usual. Hopkins agrees, noting that this would fix the downside of a November schedule which increases the delay to upgrade to a new series. He also suggests extending the security support period. Generally, every Moodle™ series gets six minor upgrades at a rate of every two months, for a year’s worth of updates; followed by 18 months of security support, 36 on the case of LTS releases, also bimonthly.
But nothing says that admins are faltering by not upgrading as soon as a new version launches. Iowan Rick Jerz points out that Moodle™ upgrades are actually available “almost continuously.” It seems Moodle version is but a number: He sets his own upgrade schedule, monthly in some of the sites under his purview, on which he upgrades to whatever the latest “branch” —on GitHub— is. He follows recommended advice from the Moodle team only in the case of serious vulnerabilities, which does not happen often.
MUA has influenced the Moodle™ software in increasingly visible ways. But few are hopeful the effects can transpire into Moodle’s inner operations. From New York, Ed Beck sums things up:
«Honestly, I wouldn’t expect Moodle™ to take a request to change the development cycle or support window seriously. I would imagine a boilerplate response along the lines of, “we offer a long term support version of Moodle™ for this exact purpose. The LTS versions are made specifically for those with special upgrade needs and the cycle is such that institutions can move from one LTS to the next.”»