Talk:Upgrade notification

About Potential problems

1 How to deal with weekly builds? - Should we include build date? What upgrade to recommend?

Perhaps we could maintain some sort of DB where we save info about each security bug fixed (or closed) and the date if was fixed (or closed!). Then, based on that information, we can recommend weeklies having security fixes included. Perhaps some custom query or report in jira: "Tell me the security bugs fixed (or closed) in last 7 days" queried on weekly generation of packages, can decide if one weekly is suitable to be reported as one "uptodate" target or no. Or, alternatively, one manual flag (and explanation) somewhere to say: "Hey, moodle.org scripts, please consider next weekly as one "uptodate" target because of this explanation". Then, each monday we can decide if next generation is going to be a "uptodate" target or no and explain why (sending those explanations in the reply IMO). One simple frontend (1 table of branch/version/explanation) should be able to allow all the parametrisation to be used in the weekly builds. --Eloy Lafuente (stronk7) 22:37, 5 October 2009 (UTC)

2 How to deal with development snapshots? Show big warning in alpha versions (==before branching)?

Perhaps same approach: Manual maintenance of branch/version/explanation? --Eloy Lafuente (stronk7) 22:37, 5 October 2009 (UTC)

3. Surely this should use the config_plugins table. No need to bloat config with this. Only admins see this on certain pages, so there is no need to save one DB query on those occasions. Otherwise, great proposal.--Tim Hunt 08:43, 6 October 2009 (UTC)

yes, thanks Petr Škoda (škoďák) 09:09, 6 October 2009 (UTC)

Update status - the Drupal way

See Enhanced status report from Moodle installation? and http://api.drupal.org/api/drupal/modules--update--update.module/6 for information on how Drupal provides such service. As a module it can be deactivated by the site administrator:

"The "Update status" module checks for available updates of Drupal core and any installed contributed modules and themes. It warns site administrators if newer releases are available via the system status report (admin/reports/status), the module and theme pages, and optionally via email."

--Frank Ralf 10:34, 6 October 2009 (UTC)

hmmm, right, it should support contrib modules too Petr Škoda (škoďák) 10:53, 6 October 2009 (UTC)

Each Drupal module provides such meta information in a very basic .info file:

; $Id: cvs_deploy.info,v 1.3 2007/06/21 09:34:59 dww Exp $
name = CVS Deploy
description = Helps sites that are deployed directly from a CVS workspace.
core = 6.x

; Information added by drupal.org packaging script on 2009-05-05
version = "6.x-1.1"
core = "6.x"
project = "cvs_deploy"
datestamp = "1241559065"

Moodle has it's own history, design and coding style, sometimes we "steal" some ideas from other projects, but I do not think we should copy everything from Drupal Petr Škoda (škoďák) 15:09, 6 October 2009 (UTC)