|
|
| (19 intermediate revisions by 2 users not shown) |
| Line 1: |
Line 1: |
| This is a proposal for the process by which we construct release notes, but does not represent a final decision.
| | #REDIRECT [[Release_Management/Release_Notes]] |
| | |
| === Release/Channel Specific Notes ===
| |
| Can be displayed above "What's New" - please get in contact with Alex to change these.
| |
| | |
| === What's New Section ===
| |
| (channel) notes for Firefox (n) should be pulled from
| |
| | |
| * bugs keyworded with "relnote"
| |
| | |
| OR
| |
| | |
| * [[Features/Release_Tracking]]
| |
| | |
| OR
| |
| | |
| * An email to Alex
| |
| | |
| OR
| |
| | |
| * has patch with approval-mozilla-(channel) added since the last merge date
| |
| * status-firefox(n) is "fixed"
| |
| | |
| === Known Issues Section ===
| |
| Let's say we're about to push Firefox (n) to Aurora. To find known issues, we should look at all bugs that are
| |
| | |
| * status-firefox(n) is "affected" or "wontfix"
| |
| * tracking-firefox(n) is "?" or "+", or tracking-firefox(n+1) is "?" or "+"
| |
| | |
| OR
| |
| | |
| * keyworded with "relnote" (perhaps this should be an approval flag)
| |
| | |
| If a bug is keyworded/flagged with "relnote", the requestor can additionally specify whether or not additional testing is required, and if so, where bugs should be filed.
| |
| | |
| === Updating Release Notes ===
| |
| | |
| All "Known Issues" (bugs) that do not have a fix date in the DB should be checked to see if they've subsequently been resolved in a newer Firefox version. This needs to happen on a weekly basis, since that's the cadence for Aurora/Beta.
| |