diff --git a/docs/contributing/pocket-guide-shipping-firefox.rst b/docs/contributing/pocket-guide-shipping-firefox.rst index b9c031a9f0e9..fdd37b962031 100644 --- a/docs/contributing/pocket-guide-shipping-firefox.rst +++ b/docs/contributing/pocket-guide-shipping-firefox.rst @@ -15,13 +15,6 @@ shipping Firefox to our users. Often this document will introduce a concept, explain how it fits into the process, and then provide a link to learn more if interested. -.. note:: - - This does not contain an overview of how we - ship :ref:`Fenix ` (Our Android browser) as - that product is largely uncoupled from how we ship to desktop and the - process we've historically followed. - Repositories & Channels ----------------------- @@ -32,19 +25,24 @@ updated within a defined cadence and built into one of our Firefox products which are released through what is commonly referred to as :ref:`Channels `: Firefox Nightly, Firefox Beta, and Firefox Release. -**Firefox Nightly** offers access to the latest cutting edge features +`Firefox Nightly `__ offers access to the latest cutting edge features still under active development. Released every 12 hours with all the -changes that have :ref:`landed ` on mozilla-central. +changes that have :ref:`landed ` on mozilla-central for Desktop and on +`main in firefox-android `__ for Android. -Every `4 weeks `__, we +Every `4 weeks `__, we :ref:`merge ` the code from mozilla-central to our -mozilla-beta branch. New code or features can be added to mozilla-beta +mozilla-beta branch. +For Android, we branch from main on firefox-android to a release branch. +New code or features can be added to mozilla-beta outside of this 4 week cadence but will be required to land in mozilla-central and then be :ref:`uplifted ` into mozilla-beta. +Similarly for Android, uplifts are required to land in main on firefox-android before +backporting to the firefox-android release branch. -**Firefox Beta** is for developers and early adopters who want to see -and test what’s coming next in Firefox. We release a new Beta version +`Firefox Beta `__ is for developers and early adopters who want to see +and test what’s coming next in Firefox. We release a new Desktop/Android Beta version three times a week. .. note:: @@ -55,14 +53,15 @@ three times a week. Each Beta cycle lasts a total of 4 weeks where a final build is validated by our QA and tagged for release into the mozilla-release -branch. +branch for Desktop. On Android we release from the same release branch +used during the Beta cycle. .. note:: **Firefox Developer Edition** *is a separate product based on the mozilla-beta repo and is specifically tailored for Web Developers.* -**Firefox Release** is released every 4 weeks and is the end result +`Firefox Release `__ is released every 4 weeks and is the end result of our Beta cycle. This is our primary product shipping to hundreds of millions of users. While a release is live, interim updates (dot releases) are used to ship important bug fixes to users prior to the next major release. @@ -74,7 +73,7 @@ weeks after the initial go-live for less-critical fixes and other :ref:`ride-along fixes ` deemed low-risk enough to include. .. note:: - **Firefox ESR (Extended Support Release)** *is a separate + `Firefox ESR (Extended Support Release) `__ *is a separate product intended for Enterprise use. Major updates are rolled out once per year to maintain stability and predictability. ESR also contains a number of policy options not available in the standard @@ -83,10 +82,12 @@ weeks after the initial go-live for less-critical fixes and other Further Reading/Useful links: +- `Firefox + Trains `__ +- `Release + Calendar `__ - `Firefox Release Process `__ -- `Release - Calendar `__ - `Firefox Delivery dashboard `__ @@ -117,8 +118,8 @@ eventually become the next version of Firefox. Further Reading/Useful links: - `Phabricator and why we use it `__ -- `Firefox Trello `__ (Distilled - list of critical features riding the trains) +- `Firefox Release Notes Process `__ +- `Firefox Release Notes Nomination `__ An exception to this process... ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -138,6 +139,8 @@ Further Reading/Useful links: - `Patch uplifting rules `__ +- `Requesting an + uplift `__ Ensuring build stability ~~~~~~~~~~~~~~~~~~~~~~~~ @@ -200,7 +203,7 @@ Further Reading/Useful links: - `Regression Engineering Owners `__ - `Commonly used Bugzilla queries for all - Channels `__ + Channels `__ Enabling/Disabling code (Prefs) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -296,15 +299,30 @@ Further Reading/Useful links: Definitions ----------- +.. _approval flag: + +**Approval Flag** - A flag that represents a security approval or uplift +request on a patch. + .. _bugzilla: **Bugzilla** - Web-based general purpose bug tracking system and testing -tool +tool. .. _channel: **Channel** - Development channels producing concurrent releases of -Firefox for Windows, Mac, Linux, and Android +Firefox for Windows, Mac, Linux, and Android. + +.. _chemspill: + +**Chemspill** - Short for Chemical Spill. A chemspill is a rapid +security-driven or critical stsbility dot release of our product. + +.. _channel meeting: + +**Channel Meeting** - A twice weekly time to check in on the status +of the active releases with the release team. .. _dot release drivers: @@ -312,6 +330,11 @@ Firefox for Windows, Mac, Linux, and Android warrant a minor dot release to the Firefox Release Channel. Usually to fix a stability (top-crash) or Security (Chemspill) issue. +.. _early beta: + +**Early Beta** - Beta releases with the features gated by EARLY_BETA_OR_EARLIER +enabled. The first 2 weeks of Beta releases during the cycle are early beta releases. + .. _feature owner: **Feature Owner** - The person who is ultimately responsible for @@ -328,6 +351,12 @@ Android based on GeckoView and Android Components **Github** - Web-based version control and collaboration platform for software developers +.. _gtb: + +**GTB** - Acronym for Go to build. Mostly used in the release schedule +communication ("Go to build on March 18"), this means that we initiate the +building of a specific release. + .. _landing: **Landing** - A general term used for when code is merged into a @@ -350,12 +379,24 @@ locally and share their changes with others. It is also called hg. **Merge** - General term used to describe the process of integrating and reconciling file changes within the mozilla repositories +.. _nightly soft code freeze: + +**Nightly Soft Code Freeze** - Last week of the nightly cycle on mozilla-central +just before the merge to beta during which landing risky or experimental code +in the repository is discouraged. + .. _normandy: **Normandy** - Normandy is a collection of servers, workflows, and Firefox components that enables Mozilla to remotely control Firefox clients in the wild based on precise criteria +.. _nucleus: + +**Nucleus** - Name of the internal application used by release managers +to prepare and publish release notes. The data in this application is +fetched by mozilla.org. + .. _orange_factor: **Orange** - Also called flaky or intermittent tests. Describes a state @@ -386,6 +427,11 @@ Firefox profile on disk (in prefs.js). **Release Candidate** - Beta version with potential to be a final product, which is ready to release unless significant bugs emerge. +.. _rc week: + +**RC Week** - The week prior to release go-live is known as RC week. +During this week an RC is produced and tested. + .. _release cycle: **Release Cycle** - The sum of stages of development and maturity for @@ -396,24 +442,29 @@ the Firefox Release Product. **Regression Engineering Owner** - A partner for release management assigned to each release. They both keep a mental state of how we are doing and ensure a decision is made about each regression reported in -the release +the release. AKA *REO*. .. _release engineering: **Release engineering** - Team primarily responsible for maintaining -the build pipeline, the signature mechanisms, the update servers, etc. +the build pipeline, the signature mechanisms, the update servers, etc. aka *releng* .. _release management: **Release Management** - Team primarily responsible for the process of managing, planning, scheduling and controlling a software build through -different stages and environments +different stages and environments. aka *relman*. + +.. _relnotes: + +**Relnotes** - Short for release notes. Firefox Nightly, Beta, and Release each ship +with release notes. .. _Repository: **Repository** - a collection of stored data from existing databases merged into one so that it may be shared, analyzed or updated throughout -an organization +an organization. .. _ride alongs: @@ -421,6 +472,21 @@ an organization considered severe enough to ship without an identified dot release driver. +.. _rollout: + +**Rollout** - Shipping a release to a percentage of the release population. + +.. _status flags: + +**Status Flags** - A flag that represents the status of the bug with +respect to a Firefox release. + +.. _string freeze: + +**String Freeze** - Period during which the introduction, modification, or +deletion of strings exposed to the end-users is not allowed so as to allow our +localizers to translate our product. + .. _taskcluster: **taskcluster** - Our execution framework to build, run tests on multiple @@ -438,6 +504,18 @@ information is used by Mozilla to improve Firefox. of distinct series of versioned software releases are released as a number of different "trains" on a regular schedule. +.. _tracking flags: + +**Tracking Flags** - A Bugzilla flag that shows whether a bug is being investigated +for possible resolution in a Firefox release. Bugs marked tracking-Firefox XX are +bugs that must be resolved one way or another before a particular release ship. + +.. _throttle unthrottle: + +**Throttle/Unthrottle a rollout** - Throttle is restricting a release rollout to 0% +of the release population, users can still choose to update but are not updated +automatically. Unthrottle is removing the release rollout restriction. + .. _uplift: **Uplift** - the action of taking parts from a newer version of a