This is a reminder that the scheduled release date of 2.9 is next Monday. We will also be releasing Moodle 2.8.6, 2.7.8 and 2.6.11.
Note that after that the 2.7 branch will be supported for security fixes only and 2.6 will no longer be supported.
See the General release calendar for upcoming release dates.
Marina Glancy
Development Process Manager, Moodle HQ
Query - If 2.7 is going to security fixes only, in the same time scales as every other point version, what was the benefit of labelling it as LTS?
Surely a LTS version should be supproted for more than just security upgrades for longer than a standard version (as well as maintaining the security upgrades for longer). Surely the whole point is that it should be supported as a 'live' version for 'long term'?
When Moodle 2.7 was announced one year ago, it was clearly stated it was LTS "for security and data loss bug fixes for 3 years". Means only for security and data loss. Support dates are also clearly on the releases page.
Of course, i understand one would want a complete LTS support.
As always, it's a matter of where to put efforts and (limited) ressources. Perhaps HQ will try to make an effort by making 6 or 12 more months complete support (the double as standard support, like for security)...
Yeah, we understand that LTS was primarily just for serious bug fixes, but it would have been nice to have the bug fixes for general core bugs scale along the serious bugs. For example, 18 -> 36 months, so something similar should be 12 -> 24 months.
A lot of things would be nice but unfortunately not all are possible. In this case we need to distribute our resources wisely among old versions and new versions.
I think we made it very clear when 2.7 was released what Long Term Support means, and while we of course want to make your life easier by offering this, we also have to push Moodle forward for the long term.
While I'm here I can assure you that 3.0 is also planned to be a LTS release.
Hi, Will there be any pattern to the LTS releases? I.e. Will it be every odd numbered release or every third release...
I would actually consider every 4th release being long term for synchronicity (is that a word?) with the standard school year. If some LTSs are released in November and some in May it might prove difficult for a standard, scheduled, upgrade path. I don't particularly care which one is the standard, just that there is a standard.
I would also prefer a LTS version every 4th release. This would allow to upgrade Moodle every 2 years to a new major version, which is quite useful for a large Moodle installation like we have.
Anyway, I am very, very glad that the HQ has started with LTS releases last year (with Moodle 2.7) and would like to thank the HQ for that very much!
Making every 4th version an LTS edition makes sense to me. This would:
However, I would also like to see the bug fix support period extended to at least 18 months, preferably 24 months. 12 months just isn't enough time to report issues and have them fixed within the same version of Moodle.
In my experience with Moodle Tracker, the process typically takes 4-8 months or more to get an issue resolved and integrated, even when the solution is provided. If you don't want to extend the period, additional effort needs to be made by Moodle HQ to shorten the turn around cycle for approving bug fixes and integrating them into Moodle.
I don't know about everyone else but we also don't start working with a new release the moment it comes out. We have to wait until 3rd party plugin developers get around to updating their code for the new Moodle version before we can begin to find issues and fix them. That alone usually takes about 6 months. X.0 versions are never a good release to go with anyway as many issues are often resolved between launch day and the x.1 release.
If the process of addressing bugs takes so long that you don't have time to integrate fixes into the LTS release, what's the point?
Security fix support is fine at 36 months.
That said, we do really appreciate Moodle HQ in making LTS versions available. I've noticed that this encourages developers to focus on that release, and even for people to feel like they have time to write books about that release. Our clients also appreciate the stability and savings from not having to upgrade as frequently with these releases. Thank you Moodle HQ!
Best regards,
Michael Milette
Damyon, perception is (generally) reality.
You can say this a lot (3.0 is 'nothing special'), but people will think otherwise.
-Derek
"If 3.0 is really 2.10 why not call it 2.10 and leave 3.0 for a version that will bring a jump like what 2.0 did?"
A good idea, but this was probably in the plan when v2.0 was released. Essentially, the current version plan can actually monster the devs. Having full version support then it is downgraded to security support only then no support comes much too quickly, I suspect. With the models above, it really makes it more desirable to just stick with the LTS versions, as long as people which versions they are.
Above, Visvanath makes the comment that suggests academia is slow to adapt, but I am not sure if that is correct, more likely funding is the issue here. Why the commercial sector would want 2 versions a year is beyond me. I would suggest they would prefer a longer cycle, as long as they get regular updates. It's like being on the edge of a wave, and you can either stay there, or you can get swamped too easily. Most organizations IT guys are already overworked, well, those I have seen anyway and those who use Moodle is one of the reasons they are. Funnily enough, one guy I spoke to told me he was really looking forward to having new versions every few months or so, is now saying they have backed off it, and are only going to upgrade once a year. Just got too much for them.
Another problem I have seen is one of the organizations I have been dealing with has parts of it on v2.7, others are on v2.8. No idea why they have done this, but I have the feeling it is going to get seriously messy if they don't remedy it. (I have not been able to talk to the network manager so have no explanation for how this happened or why, it was only by luck that I noticed it.)
"Above, Visvanath makes the comment that suggests academia is slow to adapt, but I am not sure if that is correct, more likely funding is the issue here."
"I felt that it was a dangerous generalization."
Dangerous? mmmm a generalization perhaps but the Moodles I know are all in public schools. Private schools are more likely to be using a proprietorial LMS. In this country funding to public education has been cut. Oz is one of the few nations that contribute public funding to private schools, and a substantial amount that is as well, I have not heard any screams coming from the private schools about funding cuts. Money is always an issue.
In my experience, it is not the academics it is
my 2c. I've been interested to read Martin's comments on the Association. They are having key stakeholder conversations now.
-Derek
So while perhaps some administrators would like their Moodle world to stay still there is also a lot of pressure on us for rapid evolution. Moodle needs to balance these desires.
Hi,
There was lot of changes between 1.9 and 2.0, which made the upgrade difficult for lot of people, and the goal is to avoid doing that again !
Séverin
It seems clear to me that Version 3.0 will be 1 more betterer than 2.9
Should that be 0.1 'more betterer'?
Do we need to wait for 3.9 to be a whole '1' better?
The Joomla folks did something 'different' when moving from their 1.5 to 1.6/7 to newer (2 version) ... they purposely said 2.5 ... not 2.0. They then had to have a few web pages explaining + tolerate comments in forums. It was, for those who had been using Joomla for a while, confusing for many. Not going to please everyone. Just as long as the upgrade process worked and there were no issues, then no complaints.
Unfortunately, if, in the past, a version was released that really wasn't ready for release and folks had issues ... damage done ... users naturally more cautious the next time. So, the old M$ strategy of waiting for SP1 or SP2 not such a bad idea for some. Let others be the 'omicron testers'. ;)
My 2 cents, of course!
'spirit of sharing', Ken
Dang you and your powers of numeracy Mr Olemann.
Anyone from Moodle HQ going to respond to Michael Milette's proposal? I hope that the LTS plan is not set in stone.
He makes some very good points and I believe are worth addressing. Both in having a consistent release period for an LTS version and the increased support for general bug fixes.
I can see some logic in making the LTS releases on a regular two year period so people can plan around them. So that would mean 3.1 is an LTS. This regular schedule (May every two years) works out probably better for the north hemisphere though ... the south hemisphere would be more or less forced to upgrade annually to stay on a supported LTS, which kinds defeats the purpose.
On the other hand, it's good to have the freedom to plan these LTS releases around releases that have reached a certain "plateau" of features. Sometimes we have core features integrated to stimulate more development that do not have full implementation in all core modules (eg logging/events). And it's a shame to have one of those be a LTS release and actively be encouraging people to stay there for years. In fact 3.1 would be better than 3.0 from this perspective too, given the new learning plan stuff coming in.
People keep mentioning Ubuntu as a model but I think it's a completely different type of platform with very gradual refinements. We need to think what's best for Moodle.
I can see that from the users' perspective round number of years between LTS releases is more preferable. However what really worries me here is that people will upgrade too rare and Moodle will encourage it by introducing regular LTS releases. Our deprecation policy is not designed for rare plugins upgrades. (And if institution does not have any plugins there is no need to delay upgrading at all.)
For example, if some functionality is deprecated in 2.8, it still continues to work but with debugging messages displayed. Developers have two cycles (2.8 and 2.9) to spot that their plugins use deprecated methods and upgrade them. In 3.0 the functionality that was deprecated in 2.8 is completely removed. After that plugin can not use deprecated methods at all.
If institution upgrades from 2.7 straight to 3.0 or 3.1, they skip this warning period completely and upgrading will be much more difficult, and it's more likely that students or teachers will hit exceptions on production sites.
As much as we would like our users to keep their sites secure and receive security updates for longer, we don't want to encourage to delay upgrading because of regular LTS if they otherwise would not delay it.
Please note, that at the moment I express my personal view and this is not an official HQ response. We are still discussing it and collecting opinions
My group upgrades once a year, with alternate major releases - 2.7, 2.9, etc. - upgrading over summer.
However I can see the value in two major releases per year, as not everyone will be running the same upgrade schedule as us - e.g. an Australian institution might want to upgrade over their summer break in December-January.
Yes, the reason for our six-monthly releases is explicitly to cater for both hemispheres. Down here our school year follows the calendar one, you know!
Obviously we'd love it if everyone upgraded every six months but don't worry we're very well aware this is not often possible.
... the reason for our six-monthly releases is explicitly to cater for both
hemispheres. Down here our school year follows the calendar one, you
know!
Didn't realize that, Martin. It means all those opposed to six monthly releases should be labeled as "hemispherists"!
This does not exactly contradict with what I said above. There can be different solutions to the fact that regular LTS (=more rare sites updates) do not go well together with our release and deprecation process. The easiest would be to change the deprecation time.
Believe me, lots of people want two major versions per year. In order to prevent unwanted regressions in stable version, Moodle only integrates improvements into the future major releases. So many times I've heard complains why can't users enjoy new feature straight away and have to wait for several months until the next release. Those people will be greatly disappointed if we make major releases once a year instead of twice. In fact, download.moodle.org has thousands downloads on the day of release!
And also, don't forget that forums always have more complains that praises. If somebody agrees with how things are, they don't follow the threads and don't comment there.
Hi Mark, Cambridge being in Northern hemisphere and you call June-August the summer, the first time when security issues are announced but not included in 2.8 will be July 2016. Until mid-July 2016 you are protected from hackers who are trying to exploit security vulnerabilities just as well as if you are using 2.7. I also assume that you upgrade your Moodle on the day of release of minor versions, even in the middle of summer break, because otherwise there would be even less difference for you.
Also, if you upgrade every summer, our normal 18-months support cycle works great for you since you can upgrade to 3.1, 3.3, and so on and enjoy not only security fixes but also general bug fixes during the whole year.
And the fact that you say that you will prefer to upgrade to 3.0 "because it's LTS" means that you will stay behind even when you don't need to. And it also proves my point above that we unconsciously keep users behind by introducing regular LTS.
