Installing and upgrading help

Howard, you're sort-of missing the point of the package manager there. It's not just about making the original install quick and easy, although it does do that. It's about helping you keep all the different bits of software on all the servers you manage consistent and up-to-date.

If you have a bunch of manual steps involved in each setup, you're inevitably going to end up with little wrinkles where something got set up in one place in one box and another place on another box, or you did something but forgot to document it. Ideally you want all your software in a package manager, and everything on your servers managed by a configuration management system like Puppet, so that you can be absolutely certain you know what's running on the box, and you know it's secure. A lot of sites, when they occasionally need a piece of software that doesn't have an available package, or need something at a different version, will build the package themselves then install that, rather than deploy something that the package manager and the configuration management system can't handle.

Relatedly, the point of long-term support is that you want to be confident that you can stay secure without changing the ui or the feature set. You want to do this because you may have all kinds of other people, all with their own timetables and priorities, involved in testing, checking and adapting to a new version. If you use contrib modules (one of the main benefits of using a system that's both open source and modular), you may not even know these people, and since Moodle minor version updates often break compatibility, updating and re-testing may not be a trivial job for them either.

"2.x also has long term support - we keep releasing new .x releases for Moodle 2. We spend a LOT of time making sure we don't break things (even 3rd party things) in the 2.x upgrades."

That's how Drupal does things, and there's a lot to be said for it. (I'm not sure whether or not that would be stable enough for the kind of people who run Debian Stable.) In Drupal's case it's stable enough that Drupal contrib modules are usually pegged to - say - Drupal 6.x, rather than doing what Moodle does and tying each plugin release to a minor version of core, with a branch in Git corresponding to each Moodle minor version.

But as a contrib maintainer, it's not my experience with Moodle. The changes in quiz from 2.0 to 2.1 (a very nice piece of work BTW) were really big and non-backwards-compatible and broke anything that touched it. Is that the exception to the rule, and something Moodle won't be doing again?

Have a look how Drupal is doing its releases: it releases two versions at the same time: 7.x and 7.(x+1). The odd numbers (e.g. now it is 7.13) will contain security fixes only and even (7.14) contain bugfixes and security fixes. Debian maintened package would be equivalent to those odd numbered (7.13) releases. Drupal does it this way, just to be nice to maintainers like myself.

Personally, i'd quite like to see us moving to something similar to that for Moodle. Having maintained many Moodle sites I recognise the value of being able to apply security fixes only, as many bug fixes turn into slight alterations in functionality.

But, this would require a change in 'Moodle culture'. As a project we tend to be quite liberal with our changes going into stable branches, back-porting etc. So many times its difficult to seperate security fixes like that (and this is one of the challenges as a debian maintainer). On the whole, I get the impression there is a vocal majority of users who prefer this 'liberally bugfixed' stable releases rather than tighter only necessary changes releases.

On drupal, do they sync up after each point (e.g. 7.15 contains new security fixes + 7.14 bugfixes and security) or are the odd numbers completely separate branch to even?