Release Management/Merge Documentation

⚡ Warning: This page hasn't been updated recently and may not be fully accurate or complete. In case of doubt, contact our release managers.

NOTE: For the next merge, we need to check for interface changes that are unpaired to UUID changes

NOTE: Release Engineering is now performing all code merges. The work on updating the wiki and complete automation is in progress. Hence let both RelMan & RelEng know if you find anything missing here

Archive of Past Merge Days

Release_Management/Merge_Days

What's missing here

This is a document in process, and will also be replaced by automation at some point. In the meantime it outlines the manual steps required on a 'Merge Day' when Mozilla-Aurora becomes Mozilla-Beta and Mozilla-Central becomes Mozilla-Aurora.

ATM there is nothing in here about:

• synching all the L10N repos (current doc is here for repos: L10n:Migration, and dashboard process is coming)
  • There have been issues with missing l10n locales on first beta1 builds. In m-b --> m-r migration, RelEng run l10n-sync script to uplift beta locales to release, which ensures that all locales have content in release repo and are migrated correctly. However, this script currently doesn't get used for m-a --> m-b merge day (need to check with Axel on his process here).
• Thunderbird/SeaMonkey merging, that doc is at Thunderbird/Release_Driving/Rapid_Release_Activities/Merge_Repositories

Mozilla-Beta -> Mozilla-Release Merge

For Release Engineering, this page has been superseded by https://wiki.mozilla.org/ReleaseEngineering/Merge_Duty/Steps#Perform_mozilla-beta_-.3E_mozilla-release_migration .

• Make sure that there isn't an l10n locales bug that needs to filed like: bug 826825

Close the Beta Tree

• Use https://treestatus.mozilla.org/ to close mozilla-beta.
  • Please use the "Remember previous state" option, so you can easily restore the previous status messages when you are finished (there will be a restore button at the bottom of the page).
  • In order to change tree statuses, your browserID email needs to be added with sheriff permissions (ping edmorley/philor/catlee or ask in #developers).
  • mozilla-beta will remain closed until after the Aurora->Beta uplift the following Monday (or a beta re-spin is necessary).

Sync mozilla-beta to mozilla-release

Mercurial repositories used for final releases should be synced from mozilla-beta.

Tip of default on mozilla-release should be tagged and closed. mozilla-beta should be tagged and pulled. It creates new tip of default on mozilla-release. See Aurora specific sync mechanics for the details.

L10N repositories uses noop (dummy) merge if needed to simplify localizers life.

To handle this process use the following scripts.

Beta to Release Merge day helper Script

Merge day helper script: beta2release.py

Clobber mozilla-release builders

Go to https://secure.pub.build.mozilla.org/clobberer/?branch=mozilla-release and clobber the mozilla-release builders

Running beta2release.py

Example invocation:

python beta2release.py --remove-locale sw --remove-locale ms

• Script will take-care of tagging of mozilla-beta and wil promt you to push the tag to mozilla-beta. Push by

hg -R mozilla-beta push ssh://hg.mozilla.org/releases/mozilla-beta

• Script will continue by pulling mozilla-beta to mozilla-release, merging the heads in a fast-forward manner (using hg debugsetparents), adjusting shipped-locales and changing some congigs.
• Once the diff is shown and reviewed on screen, the script will commit the changes.
• Push the final bits by

hg -R mozilla-release push --new-branch ssh://hg.mozilla.org/releases/mozilla-release

• The push should be available at https://tbpl.mozilla.org/?tree=Mozilla-Release

Uplift locales

Helper script: beta2release_l10n.sh

• Note you need permission to be able to run this script successfully.File a server ops bug similar to bug 869654
• ATM, the script uses ~/.ssh/ffxbld_dsa key to push l10n repos on befalf on ffxbld user. It can be run from cruncher.
• The script is based on Axel's merge script

Merge Day (Central, Aurora, Beta)

The bulk of the merge day work is performed by Release Engineering. However, Release Management is responsible for providing product behavior information.

Prior to sending the "Please bump & merge m-c, m-a, m-b" email, the follow steps need to be performed:

• Make sure the trees are green and as much as possible land the aurora approved patches
• Find IIDs that need to be bumped from Aurora to Beta: https://github.com/jwir3/checkiid
  • the command is -I (big 'i', not small 'L' which is what it looks like on the readme)

# run this in an updated mozilla-aurora dir
hg diff -r FIREFOX_AURORA_128_END -r tip -I "**.idl" > /tmp/firefox.diff
python /path/to/checkiid.py repo /tmp/firefox.diff

• • ie: idl files that changed on Aurora and didn't get an IID bump
  • Track on http://dxr.mozilla.org/ (Log link on the right) + http://hg.mozilla.org the new/remove methods, method profile updated, etc. Note that %{C++ declaration changes does not need to see any IID bump (no change in the vtable).
    Renaming of an argument in the function/method profile does NOT impact the IDL.
  • a const change does not require a IID bump. bug 1061656
  • report bug and n-i developers+managers to see them fixed. bug 1023109
  • OR, fix them yourself if you feel confident enough. To get a new IID, on irc, /msg firebot uuid should be enough or use ./mach update-uuids (safer)
  • need to get landed before go-to-build for 54 Beta 1 (but does not block the merge-day)
• Make final determination if any locales need to be changed for any step. (Gather bug #'s for the needed actions.)
  • The default is: central->aurora should reset to aurora, aurora->beta should take the content from aurora

Requesting the Merge

Send an email to r-d with the subject: "Please bump & merge m-c, m-a, m-b", with the following contents:

• all locales confirmed (or a list of changes needed with bug numbers)
• no config changes needed (or a list of features to enable/disable with bug numbers)
• confirm that all IDL checks have been done, and that RelMan will ensure that any remaining IDL issues are addressed prior to go-to-build for m-a.

Subject: Please bump & merge m-c, m-a, m-b

Please kick off the merge process for m-c, m-a, m-b.

Locales: The locales should be handled with the default process:  central->aurora should reset to aurora, aurora->beta should take the content from aurora
Configuration changes: There are no configuration changes we are aware of at this time.
IDL: The IDL files have been checked and there are no known issues with bumped IIDs.

Please be available for any question on irc or email.

RelEng will take the process from there, and will (eventually) reply with an email to r-d with a subject of "Bump & Merge m-c,m-a,m-b complete". When that email is received, verify that the contents confirm:

• wikimo version templates have been updated

After that email is received, continue.

Completing the Merge

• Email dev.planning and let them know the merge is complete
• Notify #developers
• Notify Release Engineering
• re-open Beta tree (leaving Aurora closed for stabilization) - https://treestatus.mozilla.org/
• Update the merge docs as needed to keep them up to date for next merge day
• Make sure you did file the bug on Aurora update throttling
• Remind Jorge that he needs to prevent an add-on compatibility bump for the hotfix add-ons

Verify the Template Version Numbers

Now that everything has been completed, verify that the template version numbers are correct. They are very important for daily cronjobs that read the values and nag many many engineers based on triage queries that use them.

• NEXT_VERSION
• CENTRAL_VERSION
• AURORA_VERSION
• BETA_VERSION
• RELEASE_VERSION
• B2G_DEV_VERSION
• ESR_VERSION (every 7 releases)
• NextReleaseDate
  • Which causes these to auto-update (with the magic of math!)
  • FIREFOX_SHIP_DATE (the next ship date)
  • FIREFOX_MERGE_DATE (the next ship date)
  • CURRENT_CYCLE based upon the calendar

Calculating the current Firefox release # and next release date

The expression reads

floor(Firefox 23 + ((current time - Firefox 23 release date) / 6 weeks))

. This expression counts the number of full 6 week increments since Firefox 23 and adds the total to 23 to give the current release number. Similarly, we can calculate the next release date with

{{#time: Y-m-d | @{{#expr: (3628800 - (({{#time: U | now}} - {{#time: U | 6 Aug 2013}}) mod 3628800)) + {{#time: U | now}}}}}}

. In this case we calculate the time since the Firefox 23 release, take the remainder from dividing by 6 weeks, and subtract that from the current time. This results in the number of days until the next release. Add that to the current time to produce the next release date.