Totara provides two levels of code updates to subscribers as part of the support agreement:

 

1. Major releases (2.4, 2.5, etc.)

 

These releases provide an opportunity to add significant features and make changes to the way the code and UI work. Each release will include an upgrade to a new version of Moodle and may include changes to the installation requirements and/or browser support.

 

There is no requirement to upgrade to the next major release until the one you are on is no longer supported (3 years after it is superseded). However upgrading will give you access to the latest features and improvements.

 

2. Minor (or point) release (2.4.5, 2.5.1, etc)

 

Minor releases provide security fixes, bug fixes and minor improvements for the existing stable branches. Keeping up to date with point releases is important for the stability and security of your site.

 

We strongly encourage you to keep your site upgraded to the latest minor release on your current stable branch.

 

The key difference is that major releases are optional and relatively infrequent whereas point releases can be necessary and regular.

 

 

Our general policy regarding features is that we only add new features to each new major release (unlike bugs, which we back-port to older stable branches). There are several reasons for this policy:

 

1. Adding new features increases the risk of introducing new bugs to the stable branches.

   It is important for customers to feel confident about applying minor releases because that's how they receive security updates and other important bug fixes. We work hard to ensure that the stable release branches are reliable and the more changes we introduce the greater the risk of introducing a regression.

   Although we test all releases, because we release a point release nearly every week we cannot be as thorough with our QA as we can for major releases so we must be careful about the extent of the changes.

 

2. Adding new features can result in unexpected interface changes that might require organisations to provide additional training on how to use the LMS.

   We are keen to avoid "moving the goalposts" for administrators and users on the stable branches. Since organisations can invest significant effort in training staff we don't want new menu items, options or features just popping up when they are not expecting changes. Limiting features to new major releases allows the organisation to plan and prepare for new features and settings when it suits them, not when they are forced to upgrade for security reasons.

 

3. New features can result in API changes which may impact 3rd party customisations. Limiting changes to the stable branches assists organisations with customisations since they only need to test and re-factor their code when they choose to upgrade major versions, not every time there is a point release.

 

 

There are some minor improvements which get included in point releases but as adoption of Totara (and hence the potential impact) grows we tend to include less.

 

Improvements which meet the following criteria are *less* likely to be included in point releases:

 

1. Database upgrades.

2. Significant amount of code changes or small changes to an area of code that can have a significant impact.

3. User interface changes, particularly changes that change existing behaviour.

 

We try to weigh up the demand and benefit of an improvement against the risk when deciding to back-port it.

 

Sometimes the line between what is a bug or an enhancement can be blurred. In these cases we use our judgement on a case-by-case basis. While we do understand that the lack of certain features can seem like a bug (in the sense that it may not behave the way you expect) but we do have to factor in the risks to all customers when making these decisions.

 

 

We do understand that it is not always possible to immediately upgrade to a new major version in order to get access to a feature you want. Perhaps you need to arrange training, or your organisation can't meet the server or browser requirements for the new version.

 

Although it is preferable to use an unmodified release when possible, another option is to back-port and apply the patch to your installation yourself. This requires a developer to update the code to work on your release and then manage the merging process when you need to update to new point release. Typically this will only be necessary until you are able to upgrade to the new release at which point the customisation will no longer apply. Managing the merging of new point releases is much more straightforward if you use a code version control system such as GIT to handle changes.

 

Please feel free to post any comments or questions you may have.

 

Simon