Release Management/Release Notes: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
(additional category test)
(Major update)
Line 1: Line 1:
{{RELEASE_MANAGEMENT_UPDATE_NEEDED}}
{{DISPLAYTITLE:Release Notes}}
<p style="font-size: larger; font-weight:bold;">This page explains how the release management team prepares release notes for Firefox.</p>


=Release Notes=
== Summarized process ==
# Towards the end of the cycle, watch the relnote-firefox flag on Bugzilla and other sources (Nightly notes, blog posts, Firefox Trello boards…)
# Create a release notes page in Nucleus for the upcoming version
# Add notes for the upcoming release in Nucleus, associate them with the right Firefox versions (ESR, release, Beta…)
# Create a shared document and list there all the notes you added in Nucleus (copy-paste) for editorial review
# Update individual notes in Nucleus from the editorial review feedback
# Add links to security advisories and developper documentation for the release
# Update Product-details with the version we ship
# Mark the release as ''is_public'' in Nucleus when we want to publish release notes


==What's the purpose of release notes?==
== What's the purpose of release notes? ==
Release notes are a central source of information about changes in each Firefox release. They're mainly aimed at advanced and technical users of Firefox who want to be informed about the changes in Firefox's latest updates. They may be web developers, IT managers who deploy Firefox for their users, or people who need to know all the details of the browser they use to accomplish their work.  Technical journalists also follow our release notes in order to write stories on changes in Firefox.  
Release notes are a central source of information about changes in each Firefox release. They're mainly aimed at advanced and technical users of Firefox who want to be informed about the changes in Firefox' latest updates.


Here is the full list of [https://www.mozilla.org/en-US/firefox/releases/ past Firefox release notes].  
They may be web developers, IT managers who deploy Firefox for their users, or people who need to know all the details of the browser they use to accomplish their work. Technical journalists also follow our release notes in order to write stories on changes in Firefox.


==How you can help with release notes==
The release notes page lists notable new features, changes or unfixed critical bugs for a specific release of Firefox. Their edition and content are under the responsibility of the release management team.
;1. Nominate fixes and features!
Anyone can go to a bug in bugzilla.mozilla.org, and nominate fixes or changes for release notes. Open the "Tracking Flags" menu on the right side of the page. Then please set the relnote-firefox: flag to "?". Release management checks this flag regularly.  


A form will pop up in the Bugzilla comments box, asking for your suggested wording for the note and an optional url to link to further documentation.  
Examples of past release notes:
* [https://www.mozilla.org/firefox//android/59.0/releasenotes/ Firefox 59 for Android]
* [https://www.mozilla.org/firefox/59.0/releasenotes/ Firefox 59 for Desktop]
* [https://www.mozilla.org/firefox/60.0beta/releasenotes/ Firefox 60 Beta for Desktop]
* [https://www.mozilla.org/firefox/61.0a1/releasenotes/ Firefox Nightly 61 for Desktop]


;2. Explain the fix
Here is the full list of [https://www.mozilla.org/firefox/releases/ past Firefox release notes].
If your fix or other project should be in release notes, tell us what it did, what it means, and what the users and tech press should know. Ideally, we link from each note to an MDN page, a blog post hosted somewhere on mozilla.org, or even a wiki page for users to understand changes, fixes, and new features.  Details are very useful here.


==What release managers do for relnotes==
The release notes for the beta and release channels are published on the day we ship Firefox or Firefox Beta to our users.
Release management may skim through the entire list of fixed bugs for a release to find possible release notes. That's often around 4000 bugs! (List of fixed bugs for the [https://bugzilla.mozilla.org/buglist.cgi?f1=target_milestone&f2=cf_status_firefox{{RELEASE_VERSION}}&j_top=OR&list_id=12572116&o1=substring&o2=anywordssubstr&product=Core&product=Firefox&product=Firefox%20for%20Android&product=Firefox%20for%20iOS&product=Hello%20%28Loop%29&product=Toolkit&query_format=advanced&v1={{RELEASE_VERSION}}&v2=fixed%2C%20verified&order=bug_status%2Cpriority%2Cassigned_to%2Cbug_id&limit=0 current release]; for [https://bugzilla.mozilla.org/buglist.cgi?f1=target_milestone&f2=cf_status_firefox{{BETA_VERSION}}&j_top=OR&list_id=12572116&o1=substring&o2=anywordssubstr&product=Core&product=Firefox&product=Firefox%20for%20Android&product=Firefox%20for%20iOS&product=Hello%20%28Loop%29&product=Toolkit&query_format=advanced&v1={{BETA_VERSION}}&v2=fixed%2C%20verified&order=bug_status%2Cpriority%2Cassigned_to%2Cbug_id&limit=0 beta]; for [https://bugzilla.mozilla.org/buglist.cgi?f1=target_milestone&f2=cf_status_firefox{{AURORA_VERSION}}&j_top=OR&list_id=12572116&o1=substring&o2=anywordssubstr&product=Core&product=Firefox&product=Firefox%20for%20Android&product=Firefox%20for%20iOS&product=Hello%20%28Loop%29&product=Toolkit&query_format=advanced&v1={{AURORA_VERSION}}&v2=fixed%2C%20verified&order=bug_status%2Cpriority%2Cassigned_to%2Cbug_id&limit=0 aurora].)
Release notes on the Nightly channel are produced continuously during the cycle. As a consequence the notes for Nightly are also available as an [https://www.mozilla.org/en-US/firefox/nightly/notes/feed/ RSS Feed] to allow testers to be notified when a new note is added to a release.


We also ask engineering managers and developer teams to tell us what note-worthy fixes are upcoming for aurora, beta, and release channels. We  check other sources like http://hacks.mozilla.org to find notable new work. In every release cycle, relman asks people on several engineering mailing lists to read release note drafts, review them, and suggest changes.  
The [https://drive.google.com/open?id=0B3Po9bsZ673yNFRLTGwtRjZGN2s Drafts of release notes] Google drive folder contains gdocs of release notes from prevous releases.


The release notes are written and managed in the [[Websites/Mozilla.org/Publishing|Nucleus interface]] available on https://nucleus.mozilla.org/.
The release management team maintains release notes for Firefox Desktop and Firefox for Android only. Release notes for other products are not in our scope at the moment.


Notable fixes and new features in more detail for developers can be found at https://developer.mozilla.org/en-US/Firefox/Releases
== How to decide whether a change should be included in release notes? ==
If you think your feature should be added to release notes, it's a good idea to nominate it for addition as soon as it is on the nightly channel.


==Aurora and Beta Cycles==
If your feature is ready for testing on the nightly channel but is behind feature flag as it isn't planned to ship on Beta/Release soon, please nominate it so as that we can expose it to our alpha-testers. The r+ flag will be set by release management only when it ships to beta/release but we have specific release notes for our alpha testers.


For the first aurora release, from the nucleus interface:
The changes that should be included in releases notes include:
* Create a new aurora release
* New features for end users and web developers
* Copy the requirements and description from the previous aurora release
* Important changes for end users and web developers
* Make sure that is_public is disabled
* Important stability and security fixes
* Ask for review to the various relevant teams (the list is available in the Release Team Calendar)  
* Important system requirements changes (ex: end of support for an OS version)
* Enable is_public on the aurora release day
* New locales


== How to nominate a bug for release notes addition? ==
=== Nomination in Bugzilla ===
1. '''Nominate a bug'''. Go to a bug in [https://bugzilla.mozilla.org Bugzilla], and nominate fixes or changes for release notes. Expand the "Tracking Flags" section. Then please set the relnote-firefox: flag to "?". Release management checks this flag regularly.
A form will pop up in the Bugzilla comments box, asking for your suggested wording for the note and an optional url to link to further documentation.
2. '''Explain the fix'''. If your fix or other project should be in release notes, tell us what it did, what it means, and what the users and tech press should know. Ideally, we link from each note to an MDN page, a blog post hosted somewhere on mozilla.org, or even a wiki page for users to understand changes, fixes, and new features. Details are very useful here.
Here is [https://youtu.be/G6VeZyOP_Rk a short video showing the above process].
Note that most of the changes impacting web developers (tooling, web standard support and new technologies) are documented on MDN which has specific pages for releases aimed at developers. The MDN team tracks these bugs with the ''dev-doc-needed'' keyword.
=== The relnote-firefox tracking flag values ===
{| class="wikitable"
|+ “relnote-firefox” tracking flag values and their meaning
|-
| --- || This bug has not been nominated for inclusion in Firefox release notes
|-
| ?  || This bug has been nominated for inclusion in Firefox release notes. <br>Please fill out the template so as to help release-drivers with formulating the actual release note content.
|-
| X+  || Drivers have determined this bug will be included in Firefox X release notes.
|-
| X+1+ || Drivers have determined this bug will be included in Firefox X+1 release notes.
|-
| X+2+ || Drivers have determined this bug will be included in Firefox X+2 release notes.
|-
| X+3+ || Drivers have determined this bug will be included in Firefox X+3 release notes.
|-
| X+4+ || Drivers have determined this bug will be included in Firefox X+4 release notes.
|-
|}
== Gathering of notes during the cycle ==
For complex software such as Firefox with thousands of patches during a cycle and external contributors, tracking what should be noted in release notes is not always easy.
Here is the main list of actions the release management team does to prepare release notes:
* Check bugs nominated for release note addition for Nightly and add them to Nightly release notes if necessary
* Check mozilla-central commits daily for features potentially note-worthy. Ping the patch author and ask her to nominate the bug for release notes addition.
* Ask engineering managers and developer teams to tell us what note-worthy fixes are upcoming for nightly, beta, and release channels.
* Check other sources such as the [https://blog.nightly.mozilla.org Nightly] and [https://hacks.mozilla.org Hacks] blogs to find notable new work.
* Ask people on several engineering mailing lists to read release note drafts, review them, and suggest changes.
We may also skim through the entire list of fixed bugs for a release to find possible release notes:
* Fixed bugs for the [https://bugzilla.mozilla.org/buglist.cgi?f1=target_milestone&f2=cf_status_firefox{{RELEASE_VERSION}}&j_top=OR&list_id=12572116&o1=substring&o2=anywordssubstr&product=Core&product=Firefox&product=Firefox%20for%20Android&product=Firefox%20for%20iOS&product=Hello%20%28Loop%29&product=Toolkit&query_format=advanced&v1={{RELEASE_VERSION}}&v2=fixed%2C%20verified&order=bug_status%2Cpriority%2Cassigned_to%2Cbug_id&limit=0 current release]
* Fixed bugs for [https://bugzilla.mozilla.org/buglist.cgi?f1=target_milestone&f2=cf_status_firefox{{BETA_VERSION}}&j_top=OR&list_id=12572116&o1=substring&o2=anywordssubstr&product=Core&product=Firefox&product=Firefox%20for%20Android&product=Firefox%20for%20iOS&product=Hello%20%28Loop%29&product=Toolkit&query_format=advanced&v1={{BETA_VERSION}}&v2=fixed%2C%20verified&order=bug_status%2Cpriority%2Cassigned_to%2Cbug_id&limit=0 beta]
* Fixed bugs for [https://bugzilla.mozilla.org/buglist.cgi?f1=target_milestone&f2=cf_status_firefox{{CENTRAL_VERSION}}&j_top=OR&list_id=12572116&o1=substring&o2=anywordssubstr&product=Core&product=Firefox&product=Firefox%20for%20Android&product=Firefox%20for%20iOS&product=Hello%20%28Loop%29&product=Toolkit&query_format=advanced&v1={{CENTRAL_VERSION}}&v2=fixed%2C%20verified&order=bug_status%2Cpriority%2Cassigned_to%2Cbug_id&limit=0 nightly]
== Notes creation ==
=== Writing Notes: step by step process ===
* Gather the notes (2 weeks ahead of release)
** Find note nominees from Bugzilla's ''relnote-firefox:? ''flag, and from the Firefox Trello board for the release.
** Put into a Google doc draft.
** Release Management & Marketing work on making sure the notes are accurate and have a verifiable source
** Checking with developerss and managers as necessary to clarify
** Ask developerss, managers, SUMO, or MDN editors to write posts and articles on mozilla.org sites so we can link to them from the notes
* Release Management emails out the draft for feedback (approximately 1 week ahead of release)
* Second editing phase
* Release Management puts the edited notes into the Nucleus back end. Each note should have a bug number associated in Nucleus, if possible
* Add a note for developer pointing to the MDN page for developers for the release:
**'''Developer''' - Changes affecting [https://developer.mozilla.org/en-US/Firefox/Releases/59 developers]
* Add a note for security fixes pointing to our security advisories, this link is provided by the Security team:
** '''Fixed''' - Various [https://www.mozilla.org/security/advisories/mfsa2018-06/ security fixes]
* Release Management sends out the links to staging to the communications team
* Final edit phase
Relevant information from the bug should be added as an item in the [https://nucleus.mozilla.org/ Nucleus database] for a specific release.
Look for the "fixed" or "verified" flag in Bugzilla to make sure the issue is fixed for the first time in that release.
=== Best practices for writing release notes ===
* Web Developer Release Notes are now added as one note and then point directly to MDN for that release (Example: https://developer.mozilla.org/en-US/Firefox/Releases/49#Changes_for_Web_developers).
* All URLs in notes should be de-localized. Typically this means removing the 'en-US/' portion of the URL.
* A note that applies to both Desktop and Android should be written once and associated with both releases.
* Don't link to bugs in the note (we do link to bugs in dot releases).
* Notes are sentence fragments. Don't start them with 'The', 'A', etc. Don't use periods. In general, unless there is a good reason the note has more than one sentence.
* Keep notes as short as possible. If you find yourself wanting to start a new sentence, figure out a way to rephrase the note.
* Do not use abbreviations. For example, "pref" should be "preference".
* Group items that belong to a category together. For example, items with WebRTC can be grouped together.
* "Developer" tag is for "Developer Tools".
* Get the release notes ready for review by requesting feedback across Mozilla. The audience reviewing this includes RelMan, release-drivers, fx-team, front-end team, SUMO team, platform-devs, QE, etc. Please follow up and close on the review feedback comments promptly.
== Nucleus: our publishing tool ==
Release notes are written and managed in [https://nucleus.mozilla.org Nucleus].
The specific release notes process for the Nightly cycle is detailed in the [[Release_Management/Nightly|Nightly cycle process]] page.
=== Nucleus and mozilla.org ===
The release notes page on mozilla.org for a specific version will not be available while the ''is_public'' flag is not selected in Nucleus but it will be available on the staging instance of mozilla.org (www-dev.allizom.org).
If a release is created in Nucleus but the release notes page doesn't have the ''is_public'' flag set to true, a "coming soon" page is displayed on mozilla.org.
There are simplified URLs for release notes that do not contain the version number and will always redirect to the latest version for the channel as provided in product-details:
* Release: https://www.mozilla.org/firefox/notes/
* Beta: https://www.mozilla.org/firefox/beta/notes/
* Nightly: https://www.mozilla.org/firefox/nightly/notes/
* ESR: https://www.mozilla.org/firefox/organizations/notes/
Mozilla.org synces with Nucleus every 15mn, depending on CDN caching it may take up to 25mn to get release notes available worldwide.
=== Creating a new release notes page ===
For the first beta release, from the nucleus interface:
For the first beta release, from the nucleus interface:
* Copy the aurora release (is_public is going to be disabled)
* Copy the nightly release (is_public is going to be disabled)
** Use the checkbox in the releases list, then the dropdown, to copy it.
* Update the title
* Update the title
* Update the date
* Update the date
* Update the description text (since aurora Text links to information about what Developer Edition is)
* Update the description text
* Ask for review (cf aurora)
* Enable ''is_public'' on the beta release day
* Enable is_public on the beta release day


During the aurora/beta cycle:
For the release, from the nucleus interface:
* Scan the relnote-firefox "?" flags
* Copy the beta release (is_public is going to be disabled)
* Try to find some important unresolved bugs
* Update the title
* Check if some features have not been disabled
* Update the date
 
* Update the description text
==Release==
* Update the notes
* Same step as Beta
* Once the notes have been signed off and the release is live, select ''is_public''.
* Once the notes have been signed off and the release is live, ''is_public'' has to be turned on.


==Product details==
Note that the System Requirements page for a release is also managed from Nucleus. If Firefox system requirements change, don't forget to update them for the release affected.
For the links in the Firefox download pages to point to the correct associated release notes, you will next need to [[Release Management/Product details|edit product details]] in svn.  


You can check the links to release notes at:
=== Release notes Categories ===


* Release: https://www.mozilla.org/firefox/new/
In Nucleus you should associate each note with a category. The notes will be grouped by category in the templated page on mozilla.org.
* Beta: http://www.mozilla.org/firefox/channel/#beta
* Aurora: https://www.mozilla.org/firefox/channel/#aurora
* ESR: https://www.mozilla.org/firefox/organizations/all/


{| class="wikitable"
|-
| New || New features
|-
| Fixed || List of known Issues that have been fixed
|-
| Changed  || Important changes to browser interface/behavior that will be valuable for Firefox end-users to know about
|-
| Developer || Issues that are of special interest to Firefox Developer audience
|-
| HTML5 || Issues related to Web platform
|-
| Unresolved || List of known issues that are not resolved in this release
|-
|}




[[Category:Release_Management|R]]
[[category:Release_Management|Release Notes]]
[[Category:Release_Management:Processes|R]]
[[category:Release_Management:Processes|Release Notes]]

Revision as of 20:39, 3 April 2018

This page explains how the release management team prepares release notes for Firefox.

Summarized process

  1. Towards the end of the cycle, watch the relnote-firefox flag on Bugzilla and other sources (Nightly notes, blog posts, Firefox Trello boards…)
  2. Create a release notes page in Nucleus for the upcoming version
  3. Add notes for the upcoming release in Nucleus, associate them with the right Firefox versions (ESR, release, Beta…)
  4. Create a shared document and list there all the notes you added in Nucleus (copy-paste) for editorial review
  5. Update individual notes in Nucleus from the editorial review feedback
  6. Add links to security advisories and developper documentation for the release
  7. Update Product-details with the version we ship
  8. Mark the release as is_public in Nucleus when we want to publish release notes

What's the purpose of release notes?

Release notes are a central source of information about changes in each Firefox release. They're mainly aimed at advanced and technical users of Firefox who want to be informed about the changes in Firefox' latest updates.

They may be web developers, IT managers who deploy Firefox for their users, or people who need to know all the details of the browser they use to accomplish their work. Technical journalists also follow our release notes in order to write stories on changes in Firefox.

The release notes page lists notable new features, changes or unfixed critical bugs for a specific release of Firefox. Their edition and content are under the responsibility of the release management team.

Examples of past release notes:

Here is the full list of past Firefox release notes.

The release notes for the beta and release channels are published on the day we ship Firefox or Firefox Beta to our users. Release notes on the Nightly channel are produced continuously during the cycle. As a consequence the notes for Nightly are also available as an RSS Feed to allow testers to be notified when a new note is added to a release.

The Drafts of release notes Google drive folder contains gdocs of release notes from prevous releases.

The release management team maintains release notes for Firefox Desktop and Firefox for Android only. Release notes for other products are not in our scope at the moment.

How to decide whether a change should be included in release notes?

If you think your feature should be added to release notes, it's a good idea to nominate it for addition as soon as it is on the nightly channel.

If your feature is ready for testing on the nightly channel but is behind feature flag as it isn't planned to ship on Beta/Release soon, please nominate it so as that we can expose it to our alpha-testers. The r+ flag will be set by release management only when it ships to beta/release but we have specific release notes for our alpha testers.

The changes that should be included in releases notes include:

  • New features for end users and web developers
  • Important changes for end users and web developers
  • Important stability and security fixes
  • Important system requirements changes (ex: end of support for an OS version)
  • New locales

How to nominate a bug for release notes addition?

Nomination in Bugzilla

1. Nominate a bug. Go to a bug in Bugzilla, and nominate fixes or changes for release notes. Expand the "Tracking Flags" section. Then please set the relnote-firefox: flag to "?". Release management checks this flag regularly.

A form will pop up in the Bugzilla comments box, asking for your suggested wording for the note and an optional url to link to further documentation.

2. Explain the fix. If your fix or other project should be in release notes, tell us what it did, what it means, and what the users and tech press should know. Ideally, we link from each note to an MDN page, a blog post hosted somewhere on mozilla.org, or even a wiki page for users to understand changes, fixes, and new features. Details are very useful here.

Here is a short video showing the above process.

Note that most of the changes impacting web developers (tooling, web standard support and new technologies) are documented on MDN which has specific pages for releases aimed at developers. The MDN team tracks these bugs with the dev-doc-needed keyword.

The relnote-firefox tracking flag values

“relnote-firefox” tracking flag values and their meaning
--- This bug has not been nominated for inclusion in Firefox release notes
? This bug has been nominated for inclusion in Firefox release notes.
Please fill out the template so as to help release-drivers with formulating the actual release note content.
X+ Drivers have determined this bug will be included in Firefox X release notes.
X+1+ Drivers have determined this bug will be included in Firefox X+1 release notes.
X+2+ Drivers have determined this bug will be included in Firefox X+2 release notes.
X+3+ Drivers have determined this bug will be included in Firefox X+3 release notes.
X+4+ Drivers have determined this bug will be included in Firefox X+4 release notes.

Gathering of notes during the cycle

For complex software such as Firefox with thousands of patches during a cycle and external contributors, tracking what should be noted in release notes is not always easy.

Here is the main list of actions the release management team does to prepare release notes:

  • Check bugs nominated for release note addition for Nightly and add them to Nightly release notes if necessary
  • Check mozilla-central commits daily for features potentially note-worthy. Ping the patch author and ask her to nominate the bug for release notes addition.
  • Ask engineering managers and developer teams to tell us what note-worthy fixes are upcoming for nightly, beta, and release channels.
  • Check other sources such as the Nightly and Hacks blogs to find notable new work.
  • Ask people on several engineering mailing lists to read release note drafts, review them, and suggest changes.

We may also skim through the entire list of fixed bugs for a release to find possible release notes:

Notes creation

Writing Notes: step by step process

  • Gather the notes (2 weeks ahead of release)
    • Find note nominees from Bugzilla's relnote-firefox:? flag, and from the Firefox Trello board for the release.
    • Put into a Google doc draft.
    • Release Management & Marketing work on making sure the notes are accurate and have a verifiable source
    • Checking with developerss and managers as necessary to clarify
    • Ask developerss, managers, SUMO, or MDN editors to write posts and articles on mozilla.org sites so we can link to them from the notes
  • Release Management emails out the draft for feedback (approximately 1 week ahead of release)
  • Second editing phase
  • Release Management puts the edited notes into the Nucleus back end. Each note should have a bug number associated in Nucleus, if possible
  • Add a note for developer pointing to the MDN page for developers for the release:
  • Add a note for security fixes pointing to our security advisories, this link is provided by the Security team:
  • Release Management sends out the links to staging to the communications team
  • Final edit phase

Relevant information from the bug should be added as an item in the Nucleus database for a specific release. Look for the "fixed" or "verified" flag in Bugzilla to make sure the issue is fixed for the first time in that release.

Best practices for writing release notes

  • Web Developer Release Notes are now added as one note and then point directly to MDN for that release (Example: https://developer.mozilla.org/en-US/Firefox/Releases/49#Changes_for_Web_developers).
  • All URLs in notes should be de-localized. Typically this means removing the 'en-US/' portion of the URL.
  • A note that applies to both Desktop and Android should be written once and associated with both releases.
  • Don't link to bugs in the note (we do link to bugs in dot releases).
  • Notes are sentence fragments. Don't start them with 'The', 'A', etc. Don't use periods. In general, unless there is a good reason the note has more than one sentence.
  • Keep notes as short as possible. If you find yourself wanting to start a new sentence, figure out a way to rephrase the note.
  • Do not use abbreviations. For example, "pref" should be "preference".
  • Group items that belong to a category together. For example, items with WebRTC can be grouped together.
  • "Developer" tag is for "Developer Tools".
  • Get the release notes ready for review by requesting feedback across Mozilla. The audience reviewing this includes RelMan, release-drivers, fx-team, front-end team, SUMO team, platform-devs, QE, etc. Please follow up and close on the review feedback comments promptly.

Nucleus: our publishing tool

Release notes are written and managed in Nucleus.

The specific release notes process for the Nightly cycle is detailed in the Nightly cycle process page.

Nucleus and mozilla.org

The release notes page on mozilla.org for a specific version will not be available while the is_public flag is not selected in Nucleus but it will be available on the staging instance of mozilla.org (www-dev.allizom.org).

If a release is created in Nucleus but the release notes page doesn't have the is_public flag set to true, a "coming soon" page is displayed on mozilla.org.

There are simplified URLs for release notes that do not contain the version number and will always redirect to the latest version for the channel as provided in product-details:

Mozilla.org synces with Nucleus every 15mn, depending on CDN caching it may take up to 25mn to get release notes available worldwide.

Creating a new release notes page

For the first beta release, from the nucleus interface:

  • Copy the nightly release (is_public is going to be disabled)
  • Update the title
  • Update the date
  • Update the description text
  • Enable is_public on the beta release day

For the release, from the nucleus interface:

  • Copy the beta release (is_public is going to be disabled)
  • Update the title
  • Update the date
  • Update the description text
  • Update the notes
  • Once the notes have been signed off and the release is live, select is_public.

Note that the System Requirements page for a release is also managed from Nucleus. If Firefox system requirements change, don't forget to update them for the release affected.

Release notes Categories

In Nucleus you should associate each note with a category. The notes will be grouped by category in the templated page on mozilla.org.

New New features
Fixed List of known Issues that have been fixed
Changed Important changes to browser interface/behavior that will be valuable for Firefox end-users to know about
Developer Issues that are of special interest to Firefox Developer audience
HTML5 Issues related to Web platform
Unresolved List of known issues that are not resolved in this release
Retrieved from "https://wiki.allizom.org/index.php?title=Release_Management/Release_Notes&oldid=1191708"