MozillaWiki

Release Management/Release Process: Difference between revisions

Page Discussion

Release Management/Release Process (view source)

Revision as of 03:59, 3 November 2022

1,952 bytes removed ,  3 November 2022
redirecting to bmo flag documentation
(redirecting to bmo flag documentation)
 
(7 intermediate revisions by 3 users not shown)
Line 22: 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 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.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 ==
== Release timeline ==
Firefox is released at intervals of four to five weeks (not counting urgent patch updates), meaning that every four to five 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 ===
=== From mozilla-central to mozilla-release ===
* 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.
* 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 4 to 5 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]].
* Firefox Beta is released three times a week for Desktop, leaving us with 9 to 12 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.
* 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.
* At the end of the Beta cycle, a final build is validated by our QA and tagged for release into the mozilla-release branch.
* At the end of the Beta cycle, a final build is validated by our QA and tagged for release into the mozilla-release branch.


Line 45: Line 45:
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.
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 lower the overall quality of Firefox during that period, we will back it out instead of waiting for a follow-up fix.
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  ==
== All about Flags  ==
[[File:Status.png|400px|right]]
See [https://wiki.mozilla.org/BMO/UserGuide#Tracking_Flags BMO documentation on Flags]
=== tracking-firefoxXX ===
A flag which show whether a bug is being investigated for possible resolution in the Firefox XX release. Bugs marked tracking-Firefox XX 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.
 
{| class="wikitable"
|+ tracking-firefoxXX
|-
| ? || This bug has been nominated to block Firefox XX
|-
|  - ||  Drivers have determined this bug will not block Firefox XX
|-
|  +|| Drivers have determined this bug will block the Firefox XX release or may be tracked after the Firefox XX release
|-
|}
 
Refer to [http://web.archive.org/web/20160417051846/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-firefoxXX ===
A flag which represents the status of the bug with respect to Firefox XX.
 
{| class="wikitable"
|+ status-firefoxXX
|-
| --- || We don't know whether Firefox XX is affected
|-
| ? || We don't know whether Firefox XX is affected, but we want to find out
|-
| unaffected || This bug does not affect Firefox XX
|-
| affected || This bug affects Firefox XX
|-
| fix-optional || This bug affects Firefox XX, we would take a fix but don't consider it as release blocking
|-
| fixed || This bug is fixed in Firefox XX
|-
| verified || This bug is fixed and verified in Firefox XX
|-
| checkin-pending || A patch for this bug was written and we are waiting for the code to be committed to the branch
|-
| disabled || This feature is disabled in Firefox XX
|-
| verified disabled || Disabling the feature is verified in Firefox XX
|-
| wontfix || A fix for this bug will not be accepted in Firefox XX
|-
|}
 
* '''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 ==
== The Process ==
Line 111: Line 60:
'''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-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.


3) 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-Firefox XX''' flag to ''fixed'', making sure [https://treeherder.mozilla.org/ Treeherder] is green.
3) 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.
 
'''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 164: Line 115:


== Getting help ==
== 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'''
* '''Mailing Lists for any release-related issue'''
** release-mgmt@mozilla.com
** release-mgmt@mozilla.com
** release-drivers@mozilla.org
** release-drivers@mozilla.org
** enterprise@mozilla.org(enterprise related issues)
** enterprise@mozilla.org (enterprise related issues)
* '''Google groups'''
* '''Google groups'''
** mozilla.dev.platform
** mozilla.dev.platform
Diannasmith
193

edits

Retrieved from "https://wiki.allizom.org/Special:MobileDiff/1226467...1244401"