Note:

If you want to create a new page for developers, you should create it on the Moodle Developer Resource site.

Talk:Upgrade notification: Difference between revisions

From MoodleDocs
No edit summary
Line 8: Line 8:


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.--[[User:Tim Hunt|Tim Hunt]] 08:43, 6 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.--[[User:Tim Hunt|Tim Hunt]] 08:43, 6 October 2009 (UTC)
: yes, thanks [[User:Petr Škoda (škoďák)|Petr Škoda (škoďák)]] 09:09, 6 October 2009 (UTC)

Revision as of 09:09, 6 October 2009

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)