Release Management/B2G Landing: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
No edit summary
(2.2 branching)
Line 253: Line 253:
* approval‑mozilla‑b2g34? - http://mzl.la/1yvEfe4
* approval‑mozilla‑b2g34? - http://mzl.la/1yvEfe4


=== Trunk/Master (currently v2.2) ===
=== v2.2 ===
<b>Open for approved patches and security fixes.</b>
==== Source Repositories ====
* Gecko: [http://hg.mozilla.org/releases/mozilla-b2g37_v2_2/ mozilla-b2g37_v2_2] ("mozilla-b2g37_v2_2")
* Gaia: [https://github.com/mozilla-b2g/gaia/tree/v2.2 v2.2 branch] ("v2.2")
* B2G Manifests: [https://github.com/mozilla-b2g/b2g-manifest/tree/v2.2 2.2] ("v2.2")
 
==== Landing Procedure ====
* sec-high and sec-critical patches have automatic approval to land if the fix has landed on all affected Firefox branches. All others must have approval‑mozilla‑b2g37+ / approval-gaia-v2.2+ to land (<b>including bugs marked as blocking-b2g:2.2+ or feature-b2g:2.2+</b>)
** If you have to land any non-blocking change, please make sure to validate your request with a strong reason to consider given the upcoming milestone and the release timeline. We request you to use approval-gaia-v2.2? for gaia and approval‑mozilla‑b2g37? for gecko to consider request uplift as necessary.<b> No guarantees on approval for non-blocking bugs, it may be granted depending on the risk/reward and how far we are in the release timeline </b>
* Follow normal landing practices for Trunk/Master.
* Unless the bug only affects that branch, the bug must be Resolved/Fixed before uplifting.
* Add a=2.2+ for security bugs or a=<whoever approved> to the end of the commit message and uplift to:
** [https://github.com/mozilla-b2g/gaia/tree/v2.2 v2.2]/[http://hg.mozilla.org/releases/mozilla-b2g37_v2_2/ mozilla-b2g37_v2_2] (setting status-b2g-v2.2:fixed)
 
==== Blocker/Approval Queries ====
* All blocking-b2g:2.2? - http://mzl.la/1pXgkjt
* Open blocking-b2g:2.2+ - http://mzl.la/1pXgp6X
* approval-gaia-v2.2? - http://mzl.la/1A21pFx
* approval‑mozilla‑b2g37? - http://mzl.la/1yvEfe4
 
=== Trunk/Master (currently v3.0) ===
<b>Open for any feature work and bug fixes.</b>
<b>Open for any feature work and bug fixes.</b>
==== Source Repositories ====
==== Source Repositories ====

Revision as of 22:13, 12 January 2015

Versions and Scheduling

See also the Rapid Release calendar for B2G.

FFOS Version Scoping Complete (Roadmap updated) Feature Landing (FL){{#info:Feature Landing (FL) is a fixed milestone in the release schedule. All feature work should be complete by the FL date}} Feature Complete (FC) Code Complete (CC) Underlying Gecko Version
v1.4 ~December 9, 2013 March 17, 2014 Apr 29, 2014 June 09, 2014 Gecko 30
v2.0 ~Mar 17, 2014 June 09, 2014 July 21, 2014 Sep 01, 2014 Gecko 32
v2.1 ~June 17, 2014 September 01, 2014 October 13, 2014 November 21, 2014 Gecko 34
v2.2 Nov 24, 2014 February 23, 2015 April 06, 2015 May 18, 2015 Gecko 37


Previous Releases

FFOS Version Scoping Complete Functional Complete (FC) Code Freeze (CF) Underlying Gecko Version Included Gecko Security Fixes Blocking bug notation End-of-life (EOL)
v1.0 (obsolete) n/a Dec 22, 2012 January 2013 Gecko 18 Gecko 18 blocking-basecamp:+, blocking-b2g:tef+ -
v1.0.1 n/a Jan 15, 2013 May 2013 Gecko 18 Gecko 20 blocking-b2g:tef+, blocking-b2g:shira+ -
v1.1.0 n/a Mar 29, 2013, with MMS/CBS/Auto-Correct waived July 2013 Gecko 18+ (new APIs) Gecko 23 blocking-b2g:leo+ March 17, 2014
v1.1.0hd n/a TBD TBD Same as 1.1.0 (merged automatically), with wvga Same as 1.1.0 blocking-b2g:hd+ March 17, 2014
v1.2.0 June 24, 2013 Sep 16, 2013 December 9, 2013 Gecko 26 Gecko 26 blocking-b2g:koi+ June 09, 2014
v1.3.0 September 16, 2013 December 9, 2013 March 3, 2014 March 17, 2014 Gecko 28 Gecko 28 blocking-b2g:1.3+ September 01, 2014


See the triage wiki page for more info about remaining blocking bugs. See this picture for an explanation of early branching (updated soon). See bug 829451 for an explanation of the version scheme.

Rough Update Graph

  • Q3 2013
    • 1.0.1 Released
  • Q4 2013
    • 1.1 Released, OEMs will update 1.0.1->1.1
  • Q1 2014
    • 1.2 Released, OEMs will update 1.1->1.1.1/2 or 1.1->1.2
  • Q2 2014
    • 1.3 Released, OEMs will update 1.1.1->1.2.1/2, 1.2->1.2.1/2, 1.1.1->1.3, or 1.2->1.3
  • Q3 2014
    • 1.4 Released, OEMs will update 1.2.1->1.3.1/2, 1.3->1.3.1/2, 1.2.1->1.4, or 1.3->1.4

Nominating Issues

See https://wiki.mozilla.org/B2G/Triage

All about approval flags

see https://wiki.mozilla.org/Release_Management/Uplift_rules

Feature Landing Criteria

  • Passes functional testing necessary to meet acceptance criteria
  • Features must not land with device automated tests disabled
  • No smoke-test, performance or checker boarding regressions
  • Includes integration/unit tests for features
  • Performance/ stability metrics maintained at least at par with previous release
  • QA and release management must be informed of all complex feature landings before the landing occurs.
    • Complex features:
      • features that have a significant amount of risk wrt destabilizing the tree
      • touches multiple modules
  • NOTE: Partial landing of features is accceptable if they pass requisite tests and acceptance criteria
    • Acceptance criteria met before being verified fixed by QA
    • Acceptance criteria should include all necessary signoffs by UX, security,product and QA.

Work Order

  • 2.0+
  • 2.1+, stabilization work for 2.1
  • other non-blocking/stabilization work for 2.0/2.1

Branch Information

See also B2G/Roadmap.

v1.3T

Open for 1.3T+ blockers.

Source Repositories

Landing Procedure

  • Patches must have blocking-b2g:1.3T+ to land.
  • Follow normal landing practices for Trunk/Master unless the but only affects the v1.3T branch.
  • Unless the bug only affects that branch, the bug must be Resolved/Fixed before uplifting.
  • Add a=1.3T+ to the end of the commit message and uplift to:
  • Bugs that also affect v1.4 (status-b2g-v1.4:affected) will be handled on a case-by-case basis for uplift. Due to the specialized nature of this branch, 1.3T+ blocking status does not grant automatic approval to uplift to v1.4. Patches must go through the regular approval process as detailed below for v1.4 consideration.
  • The v1.3 repos (b2g28 / v1.3) are regularly merged by sheriffs to the v1.3t branches. Patches with v1.3 approval should not be double-landed on the two branches.

Blocker/Approval Queries

v1.4

Open for approved patches and security fixes.

Source Repositories

Landing Procedure

  • sec-high and sec-critical patches have automatic approval to land if the fix has landed on all affected Firefox branches. All others must have approval-mozilla-b2g30+ / approval-gaia-v1.4+ to land (including bugs marked as blocking-b2g:1.4+)
  • Follow normal landing practices for Trunk/Master.
  • Unless the bug only affects that branch, the bug must be Resolved/Fixed before uplifting.
  • Add a=1.4+ for security bugs or a=<whoever approved> to the end of the commit message and uplift to:

Blocker/Approval Queries

v2.0

Open for approved patches and security fixes.

Source Repositories

Landing Procedure

  • sec-high and sec-critical patches have automatic approval to land if the fix has landed on all affected Firefox branches. All others must have approval-mozilla-b2g32+ / approval-gaia-v2.0+ to land (including bugs marked as blocking-b2g:2.0+)
  • Follow normal landing practices for Trunk/Master.
  • Unless the bug only affects that branch, the bug must be Resolved/Fixed before uplifting.
  • Add a=2.0+ for security bugs or a=<whoever approved> to the end of the commit message and uplift to:

Blocker/Approval Queries

v2.0M

Open for any feature work and bug fixes.

Source Repositories

Landing Procedure

  • Patches must have blocking-b2g:2.0M+ to land.
  • Follow normal landing practices for Trunk/Master unless the but only affects the v2.0M branch.
  • Unless the bug only affects that branch, the bug must be Resolved/Fixed before uplifting.
  • Add a=2.0M+ to the end of the commit message and uplift to:
  • Bugs that also affect v2.1 (status-b2g-v2.1:affected) will be handled on a case-by-case basis for uplift. Due to the specialized nature of this branch, 2.0M+ blocking status does not grant automatic approval to uplift to v2.1. Patches must go through the regular approval process as detailed below for v2.1 consideration.
  • The v2.0 repos (b2g32 / v2.0) are regularly merged by the device team to the v2.0M branches. Patches with v2.0 approval should not be double-landed on 2.0 and 2.0M branches.

Blocker Queries

v2.1

Open for approved patches and security fixes.

Source Repositories

Landing Procedure

  • sec-high and sec-critical patches have automatic approval to land if the fix has landed on all affected Firefox branches. All others must have approval‑mozilla‑b2g34+ / approval-gaia-v2.1+ to land (including bugs marked as blocking-b2g:2.1+)
    • If you have to land any non-blocking change, please make sure to validate your request with a strong reason to consider given the CC milestone and the release timeline. We request you to use approval-gaia-v2.1? for gaia and approval‑mozilla‑b2g34? for gecko to consider request uplift as necessary. No guarantees on approval for non-blocking bugs, it may be granted depending on the risk/reward and how far we are in the release timeline
  • Follow normal landing practices for Trunk/Master.
  • Unless the bug only affects that branch, the bug must be Resolved/Fixed before uplifting.
  • Add a=2.1+ for security bugs or a=<whoever approved> to the end of the commit message and uplift to:

Blocker/Approval Queries

v2.2

Open for approved patches and security fixes.

Source Repositories

Landing Procedure

  • sec-high and sec-critical patches have automatic approval to land if the fix has landed on all affected Firefox branches. All others must have approval‑mozilla‑b2g37+ / approval-gaia-v2.2+ to land (including bugs marked as blocking-b2g:2.2+ or feature-b2g:2.2+)
    • If you have to land any non-blocking change, please make sure to validate your request with a strong reason to consider given the upcoming milestone and the release timeline. We request you to use approval-gaia-v2.2? for gaia and approval‑mozilla‑b2g37? for gecko to consider request uplift as necessary. No guarantees on approval for non-blocking bugs, it may be granted depending on the risk/reward and how far we are in the release timeline
  • Follow normal landing practices for Trunk/Master.
  • Unless the bug only affects that branch, the bug must be Resolved/Fixed before uplifting.
  • Add a=2.2+ for security bugs or a=<whoever approved> to the end of the commit message and uplift to:

Blocker/Approval Queries

Trunk/Master (currently v3.0)

Open for any feature work and bug fixes.

Source Repositories

Landing Procedure

  • r+ is required
  • For Gaia patches, land on master or set the checkin-needed bug keyword and it will be landed for you. Once landed, the bug should be marked RESOLVED FIXED.
  • For Gecko patches, land on b2g-inbound or set the checkin-needed bug keyword and it will be landed for you.
    • b2g-inbound is regularly merged by the sheriffs to mozilla-central
    • Bugs are automatically resolved once merged to mozilla-central.

Automatic Branch Uplifts

v1.4

v2.0

v2.1

Sanity Checks

Retrieved from "https://wiki.allizom.org/index.php?title=Release_Management/B2G_Landing&oldid=1047129"