Release Management/Release Notes: Difference between revisions

Jump to navigation Jump to search

Release Management/Release Notes (view source)

Revision as of 14:43, 6 December 2023

3,840 bytes added ,  6 December 2023
Included steps for when adding a release note in Nucleus with a rollout
(Dot release information)
(Included steps for when adding a release note in Nucleus with a rollout)
 
(16 intermediate revisions by 2 users not shown)
Line 2: Line 2:
<p style="font-size: larger; font-weight:bold;">This page explains how the release management team prepares release notes for Firefox.</p>
<p style="font-size: larger; font-weight:bold;">This page explains how the release management team prepares release notes for Firefox.</p>


== 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? ==
== About Firefox 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.
Every four weeks, Firefox desktop, Firefox for Android, and Firefox for iOS release a new version of the browser. We publish release notes on [https://www.mozilla.org/firefox/releases/ mozilla.org] for an audience of web developers, tech press, and advanced and technical users of Firefox who want to be informed about the changes in Firefox's latest updates.
The release notes page lists notable new features, changes, or unfixed critical bugs for a specific release of Firefox.  


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.
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. Adding release notes content is the responsibility of the release management team, as requested by engineering/product. Release management monitor patches that land in Central during the nightly cycle and will ask about potential release note inclusion. However, release management also relies on Engineering/Product to nominate when applicable.  


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.
'''See [https://wiki.mozilla.org/Release_Management/Release_Notes_Nomination Firefox Release Notes Nomination ] for information on how to nominate release notes for Firefox.'''


Examples of past release notes:
Examples of past release notes:
* [https://www.mozilla.org/firefox//android/59.0/releasenotes/ Firefox 59 for Android]
* [https://www.mozilla.org/firefox/103.0/releasenotes/ Firefox 103 for Desktop]
* [https://www.mozilla.org/firefox/59.0/releasenotes/ Firefox 59 for Desktop]
* [https://www.mozilla.org/firefox/103.0beta/releasenotes/ Firefox 103 Beta for Desktop]
* [https://www.mozilla.org/firefox/60.0beta/releasenotes/ Firefox 60 Beta for Desktop]
* [https://www.mozilla.org/firefox/103.0a1/releasenotes/ Firefox Nightly 103 for Desktop]
* [https://www.mozilla.org/firefox/61.0a1/releasenotes/ Firefox Nightly 61 for Desktop]
* [https://www.mozilla.org/firefox/android/103.0/releasenotes/ Firefox 103 for Android]
* [https://www.mozilla.org/firefox/ios/103.0/releasenotes/ Firefox 103 for iOS]


Here is the full list of [https://www.mozilla.org/firefox/releases/ past Firefox release notes].
Here is the full list of [https://www.mozilla.org/firefox/releases/ 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 published on Merge Day at the start of a new cycle. They are maintained continuously during the Nightly cycle.  
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.


The [https://drive.google.com/open?id=0B3Po9bsZ673yNFRLTGwtRjZGN2s Drafts of release notes] Google drive folder contains gdocs of release notes from prevous releases.
Release notes for the Beta channel are published on the day we ship the first Firefox Beta of the cycle. They are maintained continuously during the Beta cycle.


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.
Release notes for the Release channel are published on the day we ship Firefox to our users. They are not maintained continuously during the Release Cycle. A new release note page is published for any dot releases during the release cycle.
The release management team maintains release notes for Firefox Desktop, Firefox for Android, and Firefox for iOS 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? ==
For questions on the process please reach out on [https://mozilla.slack.com/archives/C9L102H6X #release-notes] internal Slack channel.
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.
== Summarized process ==
# Release management creates a Nightly release notes page in Nucleus, makes the Nightly release notes public on Merge Day, and shares a link to the Nightly release notes on #release-notes.
# During the Nightly cycle, Release management monitors the relnote-firefox flag on Bugzilla and adds release notes for Nightly in Nucleus.
# Release management creates a Beta release notes page in Nucleus for the upcoming version, copies applicable notes from the Nightly to the Beta release notes,  makes the Beta release notes public in Nucleus after pushing Beta 1 live, and shares a link to the Beta release notes on #release-notes.
# Release management creates a shared document for an editorial review, copy-pastes notes from Beta Release Notes to the shared document, and shares it on #release-notes and to the release-notes mailing list,
# Engineering/Product may add notes directly to the shared document.
# Release management continues to monitor the relnote-firefox flag on Bugzilla and add release notes in Nucleus and the shared document.
# Release management/Engineering/Product performs an editorial review in the shared document.
# Release management creates a release notes page in Nucleus for the upcoming version, and copies the reviewed release notes into Nucleus.
# Release management adds links to security advisories and developer documentation for the release, and shares a link to the staging release notes on #release-notes.
# Release management makes the release notes public in Nucleus after pushing the release live.


The changes that should be included in releases notes include:
== Nightly - Gathering of notes during the Nightly cycle ==
* 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? ==
===At the start of the Nightly cycle===
=== Nomination in Bugzilla ===
* Make a copy of the previous Nightly Release in Nucleus.
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.
** Update the version and release date.
** Remove the release notes from the previous release, leaving only the nightly-only release notes.
*** Ensure the note includes the nightly version that introduced it, for example:
**** “Starting with Firefox 113, nightly builds…”
**** “Starting with Firefox 112, nightly users…”
*** Ensure to rank the nightly carry over release notes at the bottom.
* Publish the Nightly release notes after central is bumped.
* Share a link to the Nightly Release Notes on [https://mozilla.slack.com/archives/C9L102H6X #release-notes] internal Slack channel.
* Create a copy of [https://docs.google.com/document/d/1w0oz7NSHrz81KKA7FNiRHRsyhCtz5o3PVnMAKYWEEoQ/edit draft release notes doc template]
** Update the version and dates.
** Ensure the document is shared with edit access for Mozilla.


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.
===Daily during the Nightly cycle===
* Look through all patches that land in central via [https://whattrainisitnow.com/nightly/ whattrainisitnow.com]
** Identify if any patch is a candidate for release note nomination.
*** Example: New feature or behavior change.
** Needinfo the bug assignee and request if it should be considered for release note nomination
*** "'':assignee'' could you please consider nominating this for a relnote? https://wiki.mozilla.org/Release_Management/Release_Notes_Nomination"
* Review bugs that were nominated for release note inclusion.
** Check if the wording is appropriate.
** Check if the patch is nightly or early beta only.
** Check the patches that landed. If the changes are behind a pref then check if the pref value is IS_NIGHTLY_BUILD, or IS_EARLY_BETA_OR_EARLIER
** Add the release note in Nucleus.
*** Add the appropriate Tag.
*** Add the bug number in the Bug field.
*** If the note is Nightly only use a html tag to indicate it’s nightly only.
** If the release note is not Nightly only comment on the bug to inform it was added to nightly.
*** "Thanks, added to the Nightly release notes. Keeping the relnote? flag open to keep it on the radar for inclusion in our final release notes."
** If the release note is Nightly only:
*** Set the relnote flag to ''nightly+'' and add a comment:
**** "Thanks, added to the Nightly release notes"


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.
== Beta - Refining notes during the Beta cycle ==


Here is [https://youtu.be/G6VeZyOP_Rk a short video showing the above process].
===At the start of the Beta cycle===
* Create a new beta release in Nucleus.
** Copy the release notes from nightly that are riding the train.
* Copy release notes to the release notes draft document.
* Publish the release notes after pushing Beta 1 live.
* Share a link to the Beta Release Notes on [https://mozilla.slack.com/archives/C9L102H6X #release-notes] internal Slack channel.
** "FxNNN beta preliminary release notes: https://www.mozilla.org/firefox/NNN.0beta/releasenotes/. If you know of anything worth mentioning but is not yet listed, please reach out or nominate it for a release note in Bugzilla. We will follow up with a link to the Firefox NNN Release Notes document."
* Share a link to the draft release notes doc on [https://mozilla.slack.com/archives/C9L102H6X #release-notes] internal Slack channel. Include a link to the draft document and the submission deadline.
{| class="wikitable"
|-
| Hi! We're at the start of the FxNNN Beta cycle, which means it is time for a new release notes cycle!
Draft template for the Firefox NNN Release Notes is here.
The DEADLINE for submissions is ''Month Day, Year''.
This will give us time to make necessary edits and/or changes before publishing on ''Month Day, Year''.
Note: We are still monitoring relnote nomination in bugzilla via setting relnote-firefox? for FxNNN.
|}
* Send an email to the [https://groups.google.com/a/mozilla.com/g/release-notes release-notes] internal mail group. Include a link to the draft document and the submission deadline.
** Example: https://groups.google.com/a/mozilla.com/g/release-notes/c/swrd1tuRejA


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.
===Daily during the Beta cycle===
 
* Review bugs that were nominated for release note inclusion.
=== The relnote-firefox tracking flag values ===
** Check if the wording is appropriate.
** Add the release note in Nucleus and the draft document.
*** Add the appropriate Tag.
*** Add the bug number in the Bug field.
** Comment on the bug to inform that the note was added to Beta.
* If an uplift in beta is to enable a feature to ride the train, ensure to remove the nightly only note from the current nightly release notes where applicable.


===Midway through the Beta Cycle===
* Send a reminder on the  [https://mozilla.slack.com/archives/C9L102H6X #release-notes] internal Slack channel. Include a link to the draft document and the submission deadline. 
{| class="wikitable"
{| 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.
|-
|-
| Hi! We're at the mid-point of the FxNNN Beta cycle, which means it is time for a release notes reminder!
Draft template for the Firefox NNN Release Notes are here.
The DEADLINE for submissions is ''Month Day, Year''.
This will give us time to make necessary edits and/or changes before publishing on ''Month Day, Year''.
Note: We are still monitoring relnote nomination in bugzilla via setting relnote-firefox? for FxNNN.
|}
|}
* Send a reminder email to the [https://groups.google.com/a/mozilla.com/g/release-notes release-notes] internal mail group. Include a link to the draft document and the submission deadline.


== Gathering of notes during the cycle ==
== Release - Finalizing notes ==
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:
===Day before the release notes deadline===
* Check bugs nominated for release note addition for Nightly and add them to Nightly release notes if necessary
* Send a reminder on the [https://mozilla.slack.com/archives/C9L102H6X #release-notes] internal Slack channel. Reply to a thread of the previous reminder, but select to also send to channel.
* 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:
===Day after the release notes deadline===
* 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]
* Add a release note for new contributors
* 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]
** See [https://github.com/mozilla/Relman/wiki/Running-new-contributor-script Running new contributor script] for instructions on the script.
* 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]
** Use the Community category when adding the release note.
* Review the draft release notes document.
* Inform the Release Management team the document is ready for peer review.
** Another member of the team will review the release notes for clarity and/or to suggest improvements.
* Create a new release in Nucleus for Desktop, Android, and iOS.
* Add release notes from the draft release notes document.
** Add the appropriate Tag.
** Order the release notes via the ''sort num'', the order will be from highest number to lowest. Otherwise, the default order is based when the release notes were added to the release.
** Group items that belong to a category in the same order. For example, items with WebRTC can be grouped together.
** If the release note covers a feature that is part of a rollout and not enabled by default then enable '''Progressive rollout'''.
*** If rollout is only targetted at specific countries then select ''Relevant countries'' from the list of '''Available relevant countries''' 
* Set the relnote tracking flag to XXX+
* Share a link to the staged Release Notes on [https://mozilla.slack.com/archives/C9L102H6X #release-notes] internal Slack channel.
{| class="wikitable"
|-
| NNN.0 Release notes are now available on the staging server.
If there are any wording suggestions or last minute additions, please reply to this thread.
* ''link to staging Desktop release notes''
* ''link to staging Android release notes''
* ''link to staging iOS release notes''
|}
* When available add links to security advisories and developer documentation.


== Notes creation ==
== Dot-Release Notes ==
=== Writing Notes: step by step process ===
There are a few specifics to release notes for a dot-release.
* 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.
===During dot release preperation===
Look for the "fixed" or "verified" flag in Bugzilla to make sure the issue is fixed for the first time in that release.
* Evaluate if an uplift requires a release note
* Create a release in Nucleus.
** Add the release notes. Include the bug number indicated in a link between parentheses at the end.
* Add a link to the reference release notes for the major version e.g.: Reference link to [https://www.mozilla.org/firefox/102.0/releasenotes/ 102.0 release notes].
* Share a link to the staged Release Notes on [https://mozilla.slack.com/archives/C9L102H6X #release-notes] internal Slack channel.


=== Dot-Release Notes ===
== Known Issues Release Notes ==  
There are a few specifics to notes for a dot-release.
For some defects reported post-release go-live, it should be evaluated if it is useful to add a known issue to the release notes.
* Update the release notes to add a Known Issue.
** Include a link to the bug that is tracking the issue.
** If there are multiple releases on the same version include the Known Issue in the release and all dot release versions.
* After a fix for the issue has been released, edit the Known Issue:
** Format the release note text to strikethrough.
** Append the text with information in a bracket that includes the version that released the fix, for example “(Fixed in 120.0.1)”


Example: [https://www.mozilla.org/en-US/firefox/60.0.1/releasenotes/ 60.0.1 release notes]
== Release Notes Style Guide ==
Readers need to know what features are introduced/changed, the technical meaning of the feature, and the impact the feature will have on users.  


* Notes '''do''' have the bug number indicated (and linked to) between parenthesis at the end, ex: ''WebVR has been disabled by default on macOS ([https://bugzilla.mozilla.org/show_bug.cgi?id=1459362 Bug 1459362])''
* Aim to write in plain language:
* Put a link to the reference release notes for the major version with this sentence, ex: ''Reference link to [https://www.mozilla.org/firefox/60.0/releasenotes/ 60.0 release notes]''
** Avoid using technical language. We should aim to make it easy for the reader to understand. Some technical terms may be necessary depending on the release note.
* In Nucleus make the note pointing to the reference mailing list as "release-specific" and don't associate any tag to it
** Avoid using colloquialisms or idioms. These can be confusing for readers depending on their region or their native language.
** Avoid using abbreviations. For example, "pref" should be "preference".
* Avoid mentioning about:config prefs
* For new or changed features focus on how it affects the user’s experience of Firefox, not what the software itself is doing.
** Example: "To prevent session loss for inexperienced macOS users, Firefox now requests the user’s permission to install itself if it is being run from a mounted .dmg file. This request is only made the first time Firefox is run on a user’s computer."
** This could be written as "To prevent session loss for macOS users who are running Firefox from a mounted .dmg file, they’ll now be prompted to finish installation. This permission prompt only appears the first time these users run Firefox on their computer."
* For bugs focus on how the user was impacted. Start the release note with a verb in the past tense, for example Fixed, Added, Removed.
* For known issues focus on how the user is impacted. If a workaround exists ensure to use clear instructions on how to leverage the workaround.
* All URLs in release notes should be de-localized. Typically this means removing the 'en-US/' portion of the URL.
* A release note that applies to both Desktop and Android should be written once and associated with both releases.
* Don't link to bugs in the finalized release notes.
** NOTE:  Include links to bugs in dot release notes.
* Use full stops at the end of every note. The MDN [https://developer.mozilla.org/docs/MDN/Writing_guidelines/Writing_style_guide#writing_style Writing Style] is a good reference to follow for capitalization, contractions, numbers and numerals, pluralization, apostrophes and quotation marks, commas, hyphens, and spelling.


=== Best practices for writing release notes ===
== Nucleus Additonal Information==
* 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].
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.
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).


=== Nucleus and mozilla.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.
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:
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:
Line 152: Line 201:
* ESR: https://www.mozilla.org/firefox/organizations/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.
Mozilla.org syncs with Nucleus every 15mins, depending on CDN caching it may take up to 30mins for release notes to be 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.
In Nucleus you should associate each note with a category. The notes will be grouped by category in the templated page on mozilla.org.
{| class="wikitable"
{| class="wikitable"
|-
! Tag (Category) !! Use Case
|-
|-
| New || New features
| New || New features
Line 188: Line 218:
| HTML5 || Issues related to Web platform
| HTML5 || Issues related to Web platform
|-
|-
| Unresolved || List of known issues that are not resolved in this release
| Enterprise || Used to link to the enterprise release notes
|-
| Community || List of bugs fixed by community contributors this release
|-
|-
|}
|}


The ''Is known issue'' checkbox is used for issues that are not resolved in this release. They are categorized under ''Unresolved'' in the templated page on mozilla.org.
=== Adding Images ===
Release notes can include images as follows:
* Compress the image png with [https://tinypng.com/ tinypng.com]
* Use an appropriate filename that includes the release version.
* Commit the image to https://github.com/mozilla/release-notes-media/
** Please see the repo README for additional details.
* Use the image URL in the Nucleus release note with appropriate alt text.
* Example:
** Image Source: 'https://github.com/mozilla/release-notes-media/blob/main/media/115_devtools.png'
** Image URL: 'https://www.mozilla.org/media/img/firefox/releasenotes/note-images/115_devtools.png'
** Release Note: https://nucleus.mozilla.org/admin/rna/note/789608/change/
* The <code><img></code> tag can also be used, which also allows the use of <code>height</code> and <code>width</code> attributes if resizing is necessary.
** NOTE: The <code>height</code> and <code>width</code> attributes <b>must</b> be specified before the <code>alt</code> attribute or the image will not appear in the preview pane. It will still appear as expected in Bedrock, however.


[[category:Release_Management|Release Notes]]
[[category:Release_Management|Release Notes]]
[[category:Release_Management:Processes|Release Notes]]
[[category:Release_Management:Processes|Release Notes]]
Dmeehan
273

edits

Retrieved from "https://wiki.allizom.org/Special:MobileDiff/1194037...1249167"

Navigation menu