Release Management/Release Process: Difference between revisions

← Older edit

Release Management/Release Process (view source)

Revision as of 03:59, 3 November 2022

930 bytes removed , 3 November 2022

redirecting to bmo flag documentation

Diannasmith

193

edits

@@ Line 1: / Line 1: @@
+{{DISPLAYTITLE:The Firefox release process}}
 == Channels/Repositories ==
 * '''Firefox Release/[https://hg.mozilla.org/releases/mozilla-release mozilla-release]''' — The official release of Firefox.
@@ Line 21: / Line 22: @@
 * [https://play.google.com/store/apps/details?id=org.mozilla.firefox Firefox for Android]
 * [https://play.google.com/store/apps/details?id=org.mozilla.firefox_beta Firefox Beta for Android]
-* [https://play.google.com/store/apps/details?id=org.mozilla.fennec_aurora Firefox Nightly for Android]
+* [https://play.google.com/store/apps/details?id=org.mozilla.fenix Firefox Nightly for Android]
 == Release timeline ==
-Firefox is released at intervals of six to eight weeks (not counting urgent patch updates), meaning that every six to eight weeks there
+The standard release interval of Firefox is four weeks (not counting urgent patch updates), meaning that every four weeks there
-will be a new version of Firefox Release.
+will be a new version of Firefox Release. The release interval is sometimes lengthened due to holidays.
 === From mozilla-central to mozilla-release ===
-* Firefox Nightly is released every 12 hours with all the changes landed on mozilla-central.
+* Firefox Nightly contains all the changes landed on mozilla-central. Regular Nightly releases occur about every 12 hours, with additional releases generated when a Nightly release has a major problem.
-* Every 6 to 8 weeks, we merge the code from mozilla-central to our mozilla-beta branch. The mozilla-beta branch should now only get patches aimed at stabilizing the release. Any patch on mozilla-central that we want backported to our mozilla-beta branch should follow the [[Release_Management/Uplift_rules|approval rules for uplifts]].
+* Every 4 weeks, we merge the code from mozilla-central to our mozilla-beta branch. The mozilla-beta branch should now only get patches aimed at stabilizing the release. Any patch on mozilla-central that we want backported to our mozilla-beta branch should follow the [[Release_Management/Uplift_rules|approval rules for uplifts]].
-* Beta 1 and Beta 2 are built from this beta branch and used to build and ship Firefox Developer Edition as a stabilization step before shipping Firefox Beta to our much wider Beta audience.
+* Firefox Beta is released three times a week for Desktop, leaving us with 9 betas every cycle unless we have chemspills leading to additional betas. Firefox Beta 1 and 2 are shipped to a subset of our Beta population. The full Beta population gets updated starting with beta 3 only.
-* Starting with Beta 3, Firefox Beta is released twice a week for Desktop, leaving us with 12 to 16 betas every cycle unless we have chemspills leading to additional betas. Firefox Beta 3 is shipped to a subset of our Beta population. The full Beta population gets updated starting with beta 4 only.
 * At the end of the Beta cycle, a final build is validated by our QA and tagged for release into the mozilla-release branch.
 === Android specificities ===
 * Firefox Nightly is released every 24 hours
-* Starting with Beta 3, Firefox Beta is released once a week for Android, leaving us with 6 to 9 betas every cycle.
+* Firefox Beta is released once a week for Android, leaving us with 3 to 4 betas every cycle.
 Release day activities/checklist can be found on the [[Release_Management/Release_Day|Release Day wiki page]].
-Our release schedule is meant to be flexible and we may occasionally modify the length of a cycle to be shorter or longer than the 6-8 week cycle mentioned. Check the [[RapidRelease/Calendar|Rapid Release Calendar] to stay updated with the upcoming branch dates.
+Our release schedule is meant to be flexible and we may occasionally modify the length of a cycle to be shorter or longer than the 4-5 week cycle mentioned. Check the [[Release_Management/Calendar|Release Calendar]] to stay updated with the upcoming branch dates.
+=== Nightly soft code freeze ===
+The last few days of the nightly cycle, before merge day (when mozilla-central is merged into the mozilla-beta repository and a new release cycle starts), is a nightly soft code freeze, meaning that developers should not land on mozilla-central code that is deemed risky for the stability and general quality of Firefox and that features that are controlled by a pref and were not activated during the nightly cycle should not be activated during this week.
+If you land code that introduces new crashers or lowers the overall quality of Firefox during that period, we will back it out instead of waiting for a follow-up fix.
 == All about Flags  ==
-[[File:Status.png|400px|right]]
+See [https://wiki.mozilla.org/BMO/UserGuide#Tracking_Flags BMO documentation on Flags]
-* '''tracking-firefoxN''': A multi-state flag that currently has two values which show whether a  bug is being investigated for possible resolution in the FirefoxN release. Bugs marked tracking-firefoxN are bugs that must be resolved  one way or another before a particular release ships. [[Firefox/Drivers|Release drivers]] will track and shepherd the bug until it is determined the bug no longer impacts the release
-** '''''?'''''  — This bug has been nominated to block FirefoxN
-** '''''-''''' (minus) — Drivers have determined this bug will not block FirefoxN
-** '''''+''''' (plus) —  Drivershave determined this bug will block the FirefoxN release or may be tracked after the FirefoxN release
-Refer to [https://blog.mozilla.org/channels/2011/06/01/more-details-about-how-to-use-the-tracking-firefox-bugzilla-flag/ these guidelines] on setting the tracking flag
-* '''status-firefoxN''': A multi-state flag that currently has seven values which represent the  status of the bug with respect to the FirefoxN
-** ''unaffected'' — This bug does not affect FirefoxN
-** ''affected'' — This bug affects FirefoxN
-** ''fixed'' — This bug is fixed in FirefoxN
-** ''wontfix'' — A fix for this bug will not be accepted in FirefoxN
-** ''verified'' — This bug is fixed and verified in FirefoxN
-** ''disabled'' — This feature is disabled in FirefoxN
-** ''verified disabled'' — Disabling the feature is verified in FirefoxN
-<div style="clear: right"></div>
-* '''Approval Flags''': Set on the attachment of a bug
-** All patches landing on ''mozilla-beta/release/esr'' branches must have these nominated by setting a ''''' ? ''''' flag. <br>Please make sure to fill in the populated list of questions '''[Approval Request Comment]''' that come up on the attachment. This helps Release Management understand the user impact & the risk/reward analysis before we grant or deny approval. If this form is left incomplete it will be sent back to you for completion.
-[[File:ApprovalRequest.png|750px|centre]]
 == The Process ==
 ) If you think a bug needs to be addressed in a release:
-* Set the '''tracking-firefoxN: ?''' nomination on a bug for with helpful justification and keeping these [https://blog.mozilla.org/channels/2011/06/01/more-details-about-how-to-use-the-tracking-firefox-bugzilla-flag/ guidelines] in mind
+* Set the '''tracking-Firefox XX: ?''' nomination on a bug for with helpful justification and keeping these [https://blog.mozilla.org/channels/2011/06/01/more-details-about-how-to-use-the-tracking-firefox-bugzilla-flag/ guidelines] in mind
 * Mark the corresponding status flag as affected if the patch is still being worked on
 * Once the patch is ready set the approval flag appropriately depending on which branches are affected
-) Members of Release Management go through all the bugs nominated for tracking and if in agreement that this bug needs to be investigated in that release we will go ahead and set '''tracking-firefoxN: +'''. Once we track a bug for a particular release we will make sure to follow-up on the progress or help with any road blockers till you have a patch nominated for approval.
+) Members of Release Management go through all the bugs nominated for tracking and if in agreement that this bug needs to be investigated in that release we will go ahead and set '''tracking-Firefox XX: +'''. Once we track a bug for a particular release we will make sure to follow-up on the progress or help with any road blockers till you have a patch nominated for approval.
+'''Note:''' Bugs denied for ''tracking-Firefox XX'' are still important. It merely means based on the information we have now,we do not feel the bug would prevent us from shipping a release. If new information comes to light, you need help getting more data before you can make the case for us to track, or you disagree with our assessment feel free to renominate again with additional justification.
-'''Note:''' Bugs denied for ''tracking-firefoxN'' are still important. It merely means based on the information we have now,we do not feel the bug would prevent us from shipping a release. If new information comes to light, you need help getting more data before you can make the case for us to track, or you disagree with our assessment feel free to renominate again with additional justification.
+) Once you nominated a patch with '''approval-mozilla-beta/release: ?''' we will evaluate the information given in the attachment request we may either approve/deny/request more information. Once you get an approval , i.e '''approval-mozilla-beta/release: +''', sheriffs or release managers will land it on the corresponding branch and mark '''status-Firefox XX''' flag to ''fixed'', making sure [https://treeherder.mozilla.org/ Treeherder] is green.
-) Once you nominated a patch with '''approval-mozilla-beta/release: ?''' we will evaluate the information given in the attachment request we may either approve/deny/request more information. Once you get an approval , i.e '''approval-mozilla-beta/release: +''', please go ahead with landing on the corresponding branch and mark '''status-firefoxN''' flag to ''fixed'', making sure [https://treeherder.mozilla.org/ Treeherder] is green.
+'''Note:''' In the case that a tracked bug is resolved as a duplicate bug, it is best practice for the release management team to remove the tracking flag from the duplicate bug and add it to the active linked bug.
@@ Line 114: / Line 99: @@
 [[Release_Management/Relnotes_rules|Release Notes page]] describes the release notes process, the '''''relnote-firefox''''' tracking flag, styling guide and other relevant details.
-Please check the [https://wiki.mozilla.org/Release_Management/Release_Notes_Process#What.27s_New.2FKnown_Issues_Section_Candidates wiki] for the process we have currently to construct release notes. Below is the link to all the existing release notes across all channels.
+Please check the [[Release_Management/Release_Notes_Process#What.27s_New.2FKnown_Issues_Section_Candidates Release Notes documentation]] for the process we currently have to construct release notes. Below are the links to all the existing release notes across all channels.
 * '''Firefox Release'''
@@ Line 130: / Line 115: @@
 == Getting help ==
-* '''IRC'''
+* '''Matrix'''
-** irc.mozilla.org
+** https://chat.mozilla.org/#/home and apps on various platforms.
-** Some channels:#introduction, #release-drivers, #developers, #planning, #mobile
+** Useful rooms include #introduction:mozilla.org, #release-drivers:mozilla.org, and #developers::mozilla.org.
-** [https://wiki.mozilla.org/IRC More info on irc]
+** [https://wiki.mozilla.org/Matrix More info on Matrix]
 * '''Mailing Lists for any release-related issue'''
 ** release-mgmt@mozilla.com
-** release-drivers@mozilla.com
+** release-drivers@mozilla.org
-** enterprise@mozilla.org(enterprise related issues)
+** enterprise@mozilla.org (enterprise related issues)
 * '''Google groups'''
 ** mozilla.dev.platform
@@ Line 144: / Line 129: @@
 * '''Be part of the [[Firefox/Channels/Meetings|Channel Meetings]] if you are interested in day-day updates for desktop/mobile releases'''
-[[Category:Release Management]]
+[[Category:Release Management|Release Process]]
+[[Category:Release Management:Processes|Release Process]]