This is a reminder that the scheduled release date of 3.0.4 is next
Monday. We will also be releasing Moodle 2.9.6, 2.8.12 and 2.7.14.
After this date the 2.9 will be supported for security issues only. This
will be the last release for 2.8. Moodle 2.7 will be supported for
security fixes for another year.
Moodle 3.1 is expected on May 23rd and it will be another long-term support (LTS) release.
Marina Glancy
Development Process Manager, Moodle HQ
Does this mean that we are now too late to submit any last fixes for integration?
I know the schedule is published, it is easy to forget. Should you change the release schedule, so that the post like this is made when there is still time to get a patch written and submitted for integration before the release?
(Not that I had time to do anything else last week.)
Tim, release schedule is very easy - second Monday of January, March, May, July, September and November (odd months).
This reminder post is mostly for admins so they can plan the upgrade next week.
There are no additional reminders for developers about minor releases - please set up your own calendar if you need them. I do remind about the code freeze for major versions. Last one was here
P.S. This made me think that we should consider a new forum for Moodle administrators.
If you try to make that argument, then by the same logic "the release schedule is easy, there is no need to tell admins, they can put their own reminders in their calendars if they like."
That is not the point. The point is that you are trying to be helpful to some people. I made a suggestion about how you can be more helpful to more people. You can take that or leave it.
In the mean time, MDL-53744 is one bug that will not be fixed in 3.0.4, 2.9.6, 2.8.12 and 2.7.14, because I forgot, which is sad. Perhaps the release schedule is less easy if you don't work at Moodle HQ where it is the only schedule you have to think about?
The release schedule is actually really easy, and one day I might remember it - eh, probably not
What I think would be more helpful here, since this is the developer forum, is a heads up on the code freeze. This is the REAL date in my opinion.
As Tim wrote, when you don't work at Moodle HQ the timetable is not in front of you all the time. I myself am more concerned with the timetable at my workplace, and because of that these heads up posts are a big help and much appreciated. I believe similar posts about the code freeze (which I have no idea when they are) would serve a better purpose to the developers.
I know I do not qualify for an opinion here, but the fact is the graph showing the release dates posted above is far too crowded and the effective lifetime of single versions is far too short. A release schedule like this has, I suggest, few benefits and many drawbacks. The major drawback is that, as Tim pointed out, he can't serve two masters. I don't know what the arrangement is with OU, but I understand Tim is being paid by the OU. For their funding of that job, I assume, they do not begrudge Tim time to work on Moodle issues, but I would think that they would expect that much of his effort would be going to supporting OU's Moodle. There are so many Moodle Devs that do not have the kind of funding support that Tim has, so their efforts on behalf of Moodle are minimally rewarded and do not get support of their regular employers. (I know this is an issue raised and hopefully is being addressed, but it is still an issue.) And that is just one issue for the Devs.
The constant requirement to produce refinement plus new development is, I suggest, a telling flaw in the current release schedule. Either new versions will not include new tools or refinements because they are not finalized, (which would have to be happening now), or changes between versions, like v2.9 to v3.0, is not the kind of step up that the change from v1.9 to v2.0 was, where it really should be.
I doubt very many Moodle Admins will have the time to keep up with the release schedule either. I know one organization tried, and they stopped it, they could not keep up with the constant updates. I understand they are going with two updates a year now. Another organization is only one a year and another one I know is supposed to be updating from v2.5 but to what and when, is yet to be determined. When the v2.5 is no longer even enjoying security support then there is another problem altogether.
I'm with Tim on this, the demands of keeping up with such a schedule are high, and in the end, may cost more than they are worth.
Regarding the release schedule, I'm not going to say anything new:
We release updates for all supported versions every week, usually on Thursday, sometimes on Friday. This is of course far too often and admins choose when to upgrade. We aim to have stable versions upgrades to be as smooth as possible, we do not accept any changes in API or DB that can potentially break any contributed plugins.
"Minor" or "point" releases come out bi-monthly. They are no different from weeklies except for additional security issues that are only integrated right before minor release. We encourage everybody to upgrade to minor releases in order to be up-to-date with the security fixes. I post "heads up" announcement a week before minor release, then send out an email with security issues details to the admins of registered sites on the day of release and publish details of security issues on https://moodle.org/security one week after the release.
"Major" releases happen twice a year. I also remind developers about the code freeze. Code freeze is scheduled to be 5 weeks before the major release, my reminder usually goes out one week before that (a little earlier this time because release was delayed). Upgrade to the major release requires throughout testing of the contributed plugins and themes, I know that very few admins upgrade straight after the release.
This is the first time anybody asked me about the additional reminder for developer about the upcoming minor release and to be honest it surprised me. I assume it was important for Tim to see the reminder not before the minor release but before the 2.9 end-of-support. In this case you can look for the code freeze announcement because one of the versions goes out of support on the same date when another major version is released. If it helps, next time I can specifically say in the code-freeze announcement about this.
This thread was not supposed to be about me, but about improving the already good communication around releases. But since some of these points were raised:
The way way the Open University allows me (and sam marshall, Mark Johnson, and others) to contribute to Moodle core as part of our work is excellent. I appreciate it a lot, and it is always nice to be reminded that the Moodle community appreciates it a lot. (As well as threads like this, some very nice things were said at the UK/IE Moot.) However, it should not really be surprising that the OU does this. It is just enlightened self-interest. The OU gets a lot back from the Moodle community too, and we are just doing our bit as part of that. Almost all the stuff we fix is stuff that the OU needs. Perhaps the surprising thing is that more institutions are not similarly enlightened.
One of the strong points of the Moodle community is the number of active developers. Sure, the majority of code is written by HQ staff, but if you look at the stats that Dan Poltawski sometimes produces after each release, you will see that there is a very long tail of normally over 100 different developers who have each contributed at least one thing to each release.
So, I just threw out a suggestion that I thought might help developers in that long tail, who probably don't have the Moodle release schedule in the front of their minds, or linked into their diary. (Or who would normally be awake to the schedule, but are currently swamped with non-Moodle-core work in their day job.)
I completely understand Marina's point that site admins need certain types of announcements. The current messages do that well. The question is: is there a benefit in other messages targeted at developers (like the ones we now have about major release deadlines, which are great)? I think yes, but then I would not be the one who had to remember to send them.
I'm a minion at the bottom of the totem pole, and could not find out the release date for 3.1 this week.
https://moodle.org/mod/forum/discuss.php?d=332614
It was only hidden in an obscure thread. Nowhere in the docs, the release pages, the versions. (Until I added it in here: https://docs.moodle.org/dev/Moodle_3.1_release_notes)
Marina, I'm with Tim on this one. You may be surprised, you may even think developers are slack for not having reminders in their personal calendars but every little bit of support to help people in their work is useful.
ONE simple go to page with the next set of dates would help, and including any changes and links to the discussions. At present it is in three places at least, and needs a fair bit of interpretation.
My 2c
-Derek
It is not the case that there were only two warnings about the Moodle 3.1 freeze. There were plenty of them, at what felt to me like appropriate intervals, in Integration exposed.
Which I suppose is the point. I wonder how many other people (of the type of people I am thinking about) regularly read that? There are other channels too, like @moodledev on twitter.
So, you are definitely asking the right question, but now that you put me on the spot, to give a proper answer I want to know unknowable things like how many occasional Moodle devs will see announcements in various different channels?
What would probably suit me personally is:
11 weeks and 6 weeks before a major release. (11 week one aimed more at developers: get your stuff finished, and 6-week one very like now, aimed at admins, but providing the information to everyone else, is fine)
3 weeks and 1 week for minor releases. Again, first one for devs, second one for admins.
I don't care about end of support, since at the OU we have a good plan for when we do major upgrades. Including it in the other messages seems fine.
I would be really interested to see what answers other people would give.
