Difference between revisions of "Upgrade notification"

Jump to: navigation, search
(moodle.org side)
(Potential problems)
Line 48: Line 48:
  
 
=Potential problems=
 
=Potential problems=
# How to deal with weekly builds? version specification, upgrade to next weekly, etc.
+
# How to deal with weekly builds? - Should we include build date? What upgrade to recommend?
 
# How to deal with development snapshots? Show big warning in alpha versions (==before branching)?
 
# How to deal with development snapshots? Show big warning in alpha versions (==before branching)?
 
#
 
#

Revision as of 21:57, 5 October 2009

  • PROJECT STATE: Proposal, probably to be included in 1.9.x
  • 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: 2 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 new version available and 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 opt-out option ;-)

moodle.org side

Simple PHP script which accepts one optional parameter version (ex.:2007101552) and returns XML file which includes following info:

  • status - 0 (ok), 1 (needs update), 2 (not maintained)
  • update to version recommendation (ex.: 1.9.6 and 2007101560)
  • end of maintenance date if known (unix timestamp)
<?xml version="1.0" encoding="UTF-8" ?>
 <UPTODATE_INFO>
 </UPTODATE_INFO>
</xml>

Implementation

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

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

  • $CFG->uptodate_status
  • $CFG->uptodate_recommended_version
  • $CFG->uptodate_maintenance_end
  • $CFG->uptodate_fetched (date when fetched from moodle.org)

The update function is triggered:

  • every 7 days from cron.php
  • before each upgrade

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)?