Development talk:Upgrade notification: Difference between revisions
From MoodleDocs
m (New page: =About Potential problems= # 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 ...) |
|||
| Line 1: | Line 1: | ||
=About Potential problems= | =About Potential problems= | ||
# How to deal with weekly builds? - Should we include build date? What upgrade to recommend? | # 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 | :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. --[[User:Eloy Lafuente (stronk7)|Eloy Lafuente (stronk7)]] 22:37, 5 October 2009 (UTC) | ||
# 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)? | ||
:Perhaps same approach: Manual maintenance of branch/version/explanation? --[[User:Eloy Lafuente (stronk7)|Eloy Lafuente (stronk7)]] 22:37, 5 October 2009 (UTC) | :Perhaps same approach: Manual maintenance of branch/version/explanation? --[[User:Eloy Lafuente (stronk7)|Eloy Lafuente (stronk7)]] 22:37, 5 October 2009 (UTC) | ||
Revision as of 22:39, 5 October 2009
About Potential problems
- 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)
- 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)
