Upgrade notification

Moodle 2.0

• PROJECT STATE: Proposal
• MAIN TRACKER ISSUE: MDL-20438
• DISCUSSION AND COMMENTS: n/a
• AUTHOR: Petr Škoda (škoďák) + feedback and ideas from other developers
• TIME NEEDED FOR IMPLEMENTATION: 5 days

Overview

The mandatory security measure is to always keep Moodle software up to date. This page describes new mechanism that notifies each admin about available Moodle upgrades. At present upgrade information is available from moodle.org site, we are also sending new version notices via email to registered administrators. Unfortunately many sites are not upgraded regularly :-(

The general idea is that each Moodle instance contacts regularly (every 7 days) moodle.org and fetches the latest version information. Admin is notified by own server when any new version available. The notification would be also printed on the security overview report, the site notification and the front page (only when admin logged in). Admins would be also notified when branch not maintained any more.

The side effect would be that we could get much better version statistics, of course we need to provide an opt-out option ;-)

moodle.org side

Simple PHP script which accepts one optional parameter release (ex.:1.9.5+(Build:20091005)) and returns XML file which includes following info describing all branches:

<?xml version="1.0" encoding="UTF-8" ?>

<UPTODATE_INFO component="core">
 <BRANCH version="1.9">
  <VERSION>2007101560</VERSION>
  <RELEASE>1.9.6</RELEASE>
  <MAINTENANCE_END />
 </BRANCH>
</UPTODATE_INFO>

</xml>

This example contains values that would be served after the release of Moodle 1.9.6.

Implementation

New Function lib/adminlib.php/uptodate_info() - uses standard download_file_content() to fetch XML info from http://moodle.org/uptodate_info.php?release=1.9.5+(Build:20091005)

The XML info is parsed and results stored in the config_plugins table:

• uptodate|status (0 - ok, 1 - needs update, 3 branch not maintained)
• uptodate|recommended_version
• uptodate|recommended_release
• uptodate|maintenance_end
• uptodate|last_fetched (date when fetched from moodle.org)

The update function is triggered:

• every 7 days from cron.php
• after each upgrade
• when running security overview report

User interface consists of:

1. notification for admins on the admin/index.php - warning if disabled or new info can not be fetched; ok message when latest version
2. notification for admins on the front page - configurable
3. admin setting - disable fetching of info from moodle.org
4. security overview report - critical warning when disabled or not up-to-date

Potential problems

1. How to deal with weekly builds? - Should we include build date? What upgrade to recommend?
2. How to deal with development snapshots? Show big warning in alpha versions (==before branching)?