I wanted ask this question after Martins talk at the MoodleMoot UK yesterday, but there wasn't enough time.
How is the move to a fixed going to affect the update policy? In the past the policy was to support the two most recent stable versions, with a six month release cycle, this which would mean that any given point release would only be supported for 1 year.
However, I note that the updates page (http://docs.moodle.org/en/Updates) states that Moodle 2.0 will be supported till 30 June 2013, a little over 2.5 years after the first release. If I assume that all future releases will be supported for the same period of time, then by Jan 2013 by which time I would expect Moodle 2.4 to be out, then supported releases will be:
2.0 ending June 2013
2.1 ending Dec 2013
2.2 ending June 2014
2.3 ending Dec 2014
2.4 ending June 2015
Is it reasonable to assume that this will be the case? or is the long support period for 2.0 a blip caused by the need to continue 1.9 support for a long period, in which case is the support time likely to shrink back down to a shorter period for each release in order to bring things back in line with prior policy?
I would argue that the minimum period needs to be 18 months, otherwise it is likely that any institution which performs it's upgrades on an annual cycle is going to find itself using an unsupported version for a period of time at the end of the following cycle, assuming that they perform their pre-deployment testing using the current stable release, rather than the development version.
mmm You ask some difficult questions, but essentially there are a number of considerations to be made here. Let's make it clear here, I have no special information about Moodle Policy. I am not a developer, but I am on the outside looking in, and I can see somethings that are obvious to me, but have no basis in any reality other than my opinion based on observation. You can safely dismiss my comments, but hopefully you won't because they are relevant, but irreverant, insightful but obtuse.
My suspicion is that Martin has a somewhat inflexible perception of matters relating to timelines. This does not mean his ideas are not sound, just sometimes the Cassandra syndrome simply eludes him altogether. Like some general once said, even great a plan lasts only as long as the enemy complies with it. So it is with software development. This is an incredibly complex operation, that is overlaid by 16 odd time zones, plus a loosely conjoined common interest group, and an everchanging technical base. That Martin has managed to marshall Moodle as he has is remarkable, so little wonder that things do not always comply with his wishes.
There was a recent discussion about how long support for v1.9.x would continue. It was suggested by Martin that support be cut by July and ended by December I think it was. The logic was that those people tied up on v1.9.x would better serve the cause by devoting their time to v2.x. Also, there would be a reduction to the risk of damaging both versions by someone writing v1.9.x code for 2.x or vice versa. Logical, and perceptive, but not workable, as the major institutions are planning on moving to v2.x during the northern summer in 2012. I think that throws Martin's original schedule out a bit. Another thing that could cause a huge amount of disturbance is the possibility of another financial collapse like we saw in 2009. Something like that is just going to cause a huge number of problems for everyone, Moodle too. Ironically, this may also prove a bonus for Moodle, the number of programers with the requisite skills to work on Moodle code may want to devote time to Open Source projects just to keep their skill levels current could greatly benefit Moodle. If so, then by June of 2015, we could be using Moodle 2.6. But my prescience fails me here Cassandra, I am not.
Under these circumstances, I suggest that, from time to time, reality has an impact that makes a big difference between the announced decisions and the actual result, and it pays no attention to intentions.
That's a really good question. I think it's safe to assume that there will probably not be five releases simultaneously supported, as that's far too much work for developers. But I have no idea what Martin plans.
One possibility would be to make certain releases 'LTS' releases (like 1.9 is). For example, say odd numbered releases get 2 years of support
2.0 - supported until 2.2 release (1 year)
2.1 - supported until 2.5 release (2 years)
2.2 - supported until 2.4 release (1 year)
2.3 - supported until 2.7 release (2 years
etc.
That would leave 3 releases currently supported at any given time (er, I think).
This is just my random thoughts, I have no idea what Martin wants to do, but supporting 5 releases at once sounds like too many.
--sam
LTS releases would make a lot of sense to me, I personally value the long term stability of a platform over having the latest and greatest features.
One other thought that occurs to me, how far ahead on average do colleges normally start evaluating a new release for deployment during the summer holiday? If this hasn't been done already, it might make sense to find this out and sync the release cycle to the approximate dates when this evaluation starts, that would keep the supported period for any given release to a minimum.
It also seems likely to me that the 6 month cycle combined with the annual upgrade cycle of colleges means that northern and southern hemisphere colleges are in the future likely to always be on different point releases, eg in the south I would expect the following pattern (assuming that they test with the current stable release 3 months ahead of deployment) :
Jan 2012 - 2.1
Jan 2013 - 2.3
Jan 2014 - 2.5
While the north would go:
Jul 2011 - 2.0 (although the majority of colleges are probably skipping this one)
Jul 2012 - 2.2
Jul 2013 - 2.4
This is merely an observation (which could end up being wrong if a significant proportion of colleges go for the latest version on release at the point of upgrade), i'm not sure what the impact of this would be. It could be a good or bad.
One other thought that occurs to me, how far ahead on average do colleges normally start evaluating a new release for deployment during the summer holiday? If this hasn't been done already, it might make sense to find this out and sync the release cycle to the approximate dates when this evaluation starts, that would keep the supported period for any given release to a minimum.
It also seems likely to me that the 6 month cycle combined with the annual upgrade cycle of colleges means that northern and southern hemisphere colleges are in the future likely to always be on different point releases, eg in the south I would expect the following pattern (assuming that they test with the current stable release 3 months ahead of deployment) :
Jan 2012 - 2.1
Jan 2013 - 2.3
Jan 2014 - 2.5
While the north would go:
Jul 2011 - 2.0 (although the majority of colleges are probably skipping this one)
Jul 2012 - 2.2
Jul 2013 - 2.4
This is merely an observation (which could end up being wrong if a significant proportion of colleges go for the latest version on release at the point of upgrade), i'm not sure what the impact of this would be. It could be a good or bad.
In reply to Tim Williams
This forum post has been removed
The content of this forum post has been removed and can no longer be accessed.
You really hit the nail on the head here. The real problem is not the length of the support but when the versions are released.
I'm a high school teacher. I started running a server for my own classes and I'm graduating next year to running one for the teachers interested at my school. If I'm going to upgrade to a major release version its going to happen only during Christmas break or Summer break. Since I'm a one man army I can't do extensive testing which means I'm also likely to wait for the first point release before I upgrade (2.X.1).
Right there on the current schedule, I'm skipping all the even releases because of timing unless I want 2.X.0+. The summer odd numbered release will work much more nicely because there is more time since we start school at the end of August.
If the major releases happened in April and October it would probably work out for better timing.
In reply to sam marshall
This forum post has been removed
The content of this forum post has been removed and can no longer be accessed.
Strange but true: An admin tasked with setting up Moodle today and picking the version with the longest possible support is going to be SOL for security fixes in one year (*). Its useful life is going to be even shorter if they have to do some testing and training on the new thing before they migrate.
I don't know about anyone else, but the lack of an LTS release would give me serious pause for thought before recommending Moodle to a client, however good the features are.
(* Actually that's not quite true, they'd get another 6 months if they installed 1.9...)
That's not true at all. I've committed Moodle HQ resources to security fixes for 18 months for each release (it says that on the page you linked), and even beyond that we will integrate fixes that are backported by others in the community. That's a lot of resources we are putting in.
If you want to have Moodle for free AND have old versions maintained for many years then consider putting something back into the project.
Thanks for your response, Martin, and I do appreciate the effort you guys are putting into Moodle.
On integrating fixes backported by the community, would you say that without you promising it, in practice admins can have a reasonable expectation that they'll be able to carry on running these versions beyond the dates listed?
For example, looking at the updates page, the latest-supported date I can see, if I were to install now, would be June 2013. (OK, that's 1 month more than a year...)
I read that to mean that since I wouldn't be able to get security updates for it, it wouldn't be responsible to advise a client to install it unless they were prepared to put more resources into upgrading, testing and potentially training on a new version ahead of June, 2013.
Hi Edgar, I was somewhat surprised to read your comments above, but having been trapped by technology updates, I understand what you are saying. I do not want to appear as the evangelical here, but it is my perception that what you are referring to would be relating to a commercial product. Understandably, you would want more time with it, creating the perception of "better value" before we have to fork out for another expensive update, but this is a self delusion we all indulge in I suspect. Even at an 18 month cycle, we are not talking massive updates with Moodle, we are not talking "new" product, we are talking about enhanced and greatly improved product.
v1.9 was around for considerably longer than 18 months, and the differences between 1.9.0 and 1.9.16+ were substantial, but not cosmetically, and were responses to changing uses, changing technologies, increasing security requirements, some changing legal requirements I suspect, and greater efficiencies within the code. I suggest this applies also to v2.x, but even more so. The initial changes and responses to newer technologies demand more frequent updates, and a more consistent update pattern from Moodle.org.
In the end though, Adobe has a new version of CS about every 2 years, The Dark Side tends to take its time so may take 3-4 years for any of its products. Both Adobe and the Dark Side have definitive EOL policies as well as infrequent "service pack" releases. Moodle has changed that to monthly updates, and this means your clientele can be up with the latest and greatest every month, if they wish. Most large organizations though have, for some reason, really slow updating policies - a reflex over the major commercial companies maximization of profit strategies I would suggest. Moodle is not constrained by the profit motive, so can, in its own way, show that a product can evolve in ways that commercial products do not, can be better than what they were, far more quickly.
I would think that this strategy would also be recognised as rapid reaction to market demands, changing social demands, changing technical and technology demands. For me, this makes Moodle.org's strategy a sound idea. Where it might come unstuck is with companies and organizations who are so used to having to wait for years even for a simple bug fix they cannot cope with such an apparently rapid changing product. Upgrading Moodle, btw, is actually a lot easier than upgrading anything from the Dark Side, and providing you pay attention to what you are doing and test everything first, it can be quite smooth. To reveal my own limitations here, though, I run 2 Moodles, neither larger than 100 users, privately, and both are safely on v2.2. I will not be updating them agan before the next major release. My school Moodles vary location to location, but I have no control over updates there.
Just to note, this is not at all a unique situation.
For example, if you use Java, Oracle will give you free security updates, but the older versions are EOLed after a time and stop receiving these. Java 6 EOL is currently set at November 2012, which follows the Java 7 developer release in July/November 2011 and the end-user release... er... two weeks ago.
If you want, you can pay through the nose to Oracle and get security updates to older Java versions - even really ancient ones. I'm sure some Moodle partners will offer this service for Moodle.
At the OU we sometimes manually apply some of the serious security updates to avoid having to take Moodle point updates (2.1.1 -> 2.1.2 say) when we aren't ready for them. Obviously doing this costs us time/money but it doesn't seem unreasonable on Moodle's part to me - most people will just apply the point updates, we want something special, we have to pay for it. Similarly if we want to sit on a major version for eighteen months before updating, we'd have to pay (again, either in time or money) to backport security fixes. Also not unreasonable.
With regard to the relatively frequent updates, rather than the EOL policy I think we'd have a bigger concern here about API changes (because of all our custom plugins) and large-system performance issues.
--sam