Releases/Firefox 13.0b1/BuildNotes: Difference between revisions
(Created page with "=Notes About Releasing= Please update the [https://wiki.mozilla.org/index.php?title=Releases/BuildNotesTemplate Notes Template] and the [https://intranet.mozilla.org/Build:Releas...") |
|||
Line 8: | Line 8: | ||
=Build Engineers= | =Build Engineers= | ||
{ | {jhford} - Tracking bug: {{bug|744590}} | ||
=Signed-off Revision(s)= | =Signed-off Revision(s)= |
Revision as of 00:39, 25 April 2012
Notes About Releasing
Please update the Notes Template and the Release:Primer for future releases (bug fixes, changes to automation) as needed
Bugs hit
Enter any bugs pre-existing or newly discovered and filed during the release:
- bug - description
Build Engineers
{jhford} - Tracking bug: bug 744590
Signed-off Revision(s)
Build 1: #
L10N changesets
Instructions on how to get them
- Firefox: link to the l10n-changesets
- Fennec: link to the json
Tags
Manually tag the automation code, then record the generated tags below. (details)
Build # | Branch, Tags | Changeset |
MOBILE80_#_RELBRANCH, FENNEC_VERSION_RELEASE, FENNEC_VERSION_BUILD1 | # | |
GECKO80_#_RELBRANCH, FIREFOX_VERSION_BUILD1 FIREFOX_VERSION_RELEASE | # |
Build data
Firefox
Build # | Type | Build ID | Build machine | Time to build |
1 | Linux | |||
Linux64 | ||||
Mac | ||||
Windows |
Fennec
Build # | Type | Build ID | Build machine | Time to build |
1 | android | |||
android-xul |
Notes
Build 1
Diff mozconfigs
If this is a *.0 beta -> release. May also need to update the whitelist of nightly vs release differences for release sanity.
Preparing to start Automation
- Set clobbers for the appropriate masters. Doing this 24-48 hours in advance should speedup the build.
- Reserve slaves, e.g.:
[cltbld@buildbot-master08 master]$ pwd /builds/buildbot/build1/master [cltbld@buildbot-master08 master]$ cat reserved_slaves_bm08-build1 8
- For build1 only, create a symlink for your $version (eg 11.0b4, 10.0.2esr, 10.0.2, 3.6.27) (until bug 725839 is resolved)
# ffxbld@stage cd /pub/mozilla.org/firefox/nightly/ mkdir ../candidates/$version-candidates ln -s ../candidates/$version-candidates $version-candidates
- Update l10n changesets for desktop, mobile
- Instructions on how to get them
- dashboard
- Land automation configs (are you or buildduty going to reconfig? great, merge. otherwise double-land only your configs)
- Tag buildbot-configs, buildbotcustom, & tools with build & release tags. (details)
- Sample command for Firefox 10.0 beta 5 build 1:
hg tag -f FIREFOX_10_0b5_RELEASE FIREFOX_10_0b5_BUILD1 hg tag -f FENNEC_10_0b5_RELEASE FENNEC_10_0b5_BUILD1 # bash shortcut: hg tag -f {FIREFOX,FENNEC}_10_0b5_{RELEASE,BUILD1}
- update and reconfigure the master
- start automation ← monitor progress on buildbot (e.g. beta)
- reconfigure other masters (or ask the buildduty person to do this) if you have done a merge (and not double-land) to production
E-mail Metrics
Use the address "metrics-alerts < AT > mozilla < PERIOD > org"
For 3.6.25 you would send
Firefox,firefox,firefox,3.6.25,3.6 Firefox,firefox,firefox,3.6.26pre,3.6
For non-3.6 releases, we need to include Fennec in the email if we build Fennec.
For 9.0b2 it would be
Firefox,firefox,firefox,9.0b2,9.0 Fennec,firefox-mobile,fennec,9.0b2,9.0
And for 9.0 final it's
Firefox,firefox,firefox,9.0,9.0 Fennec,firefox-mobile,fennec,9.0,9.0
ESRs look like this:
Firefox,firefox,firefox,10.0.3,10.0 Firefox,firefox,firefox,10.0.3esr,10.0
E-mail mirrors@mozilla.org
Not necessary for rapid release betas, files only go as far as the 'internal mirrors'.
Coordinate yourself with the person creating the ESR and the latest release which normally go out at the same time.
They want to know approximately what time push to external mirrors will occur. Ideally this is a 24hr notice to them, with the estimated time.
Subject: Firefox {VERSION1} [and {VERSION2}] coming to mirrors on {DATE} Body: We're planning on pushing our Firefox {VERSION1} [and {VERSION2}] release(s) to mirrors 24 hours before {DATE}. # If this is a chemspill, please mention that in the email as it will mean pinging # for CDN to be enabled when the push to internal mirrors happens If you believe these releases or these dates will cause any problems, please notify release at mozilla.com. If you have any problems with mirror status/weights/etc, please notify mirror-submissions at mozilla.org.
Edit rsync exclude files
Edit /pub/mozilla.org/zz/rsyncd-mozilla-releases.exclude on stage so that it excludes the current release. This prevents external mirrors from picking up the new release prematurely.
For rapid release betas, this is not necessary as there's already an exclude that matches beta releases.
Tag
Bouncer Submitter
Source
Build
Firefox
Firefox repacks
Fennec
Fennec repacks
Unittests / Talos
- Look to see that they ran
- Document any oranges (per platform) for unittests - if possible, try to confirm it's known/random
- Make sure there's no red/failures that we need to have a dev look at
XULRunner
Source
Build
Partner Repack
Firefox
Fennec
Android Signing
Instructions in MobileSigning
Now run on signing1.
L10N verify
Checksums
Updates
Update verify
Major Update
Major update generation is not kicked off automatically. You should only create them once the final builds for the "latest" build are ready. For instance, the 3.6.26 builds got created a week before the 10.0 release but the "final" 10.0 builds were not created after few days.
Follow instructions from the Major update documentation.
Major Update verify
Reset reserved slaves
Check permissions / AV scan
It is supposed to be triggered automatically after updates are done. File a bug if it doesn't. details
Push to internal mirrors
This is done by automation for rapid release betas.
For other releases, this should be done manually at this point, after check permissions / AV scan have completed.
- Make sure the rsync excludes have been updated (Releases/BuildNotesTemplate#Edit_rsync_exclude_files)
- Force build the push to mirrors builder. Make sure at least 15 minutes have elapsed since editing the rysnc module to give it time to sync out.
Final verification
Record receipt of "completed_final_verification" emails (1 per platform)
Going to Beta
NOTE: Skip to "Before Release Day" for beta releases
Run backupsnip
NOTE: Remember to do this at least 2 hours ahead of the expected "go to beta" email. details
Push to beta
Wait for "go" from release managers
For Firefox:
- Publish (and record run time here): details
- on completion, email r-d that VERSION updates are live on the beta channel
For Android:
- publish on Google Play (nee Android Marketplace), using instructions below
- on completions, email r-d that VERSION is live on Google Play
Wait for confirmation from QA that each of the above releases is okay, then close the tracking ticket.
Before Release Day
Assuming this is not a chemspill.
Run backupsnip for release snippets
Do this the night before release day as it can take up to two hours.
Push index file to mirrors
Push to external mirrors
If this is a chemspill you will want to ping justdave (or other sysadmin) in #release-drivers and ask them to enable CDN.
- Remove previously added blacklisting entry from stage.mozilla.org:/pub/mozilla.org/zz/rsyncd-mozilla-releases.exclude
- Replace old version with the current one in stage.mozilla.org:/pub/mozilla.org/zz/rsyncd-mozilla-current.exclude
See details
Release Day
Publish Fennec to the Play Store (for beta releases and release releases)
Push the files (for beta releases and release releases)
- Use this script and run it as ffxbld@stage (please push you changes prior to using it, and grab latest on stage via curl -O http://hg.mozilla.org/build/braindump/raw-file/tip/releases-related/push_fennec.sh)
Play Store (for beta releases and release releases)
IMPORTANT - Make sure to follow instructions!
- download multi apk (e.g. multi/fennec-10.0b6.multi.android-arm.apk)
- visit https://market.android.com/publish
- choose "Firefox Beta" or "Firefox"
- select the "APK Files" tab and choose "Upload APK"
- choose the multi apk that you downloaded and hit "upload"
- NOTE: the progress bar does not seem to show progress (at least on Google Chrome)
- when it finishes uploading, verify VersionCode is the build date (almost anyway, the market reports an hour later than our buildID)
- hit "Save"
- choose the multi apk that you downloaded and hit "upload"
- activate new apk (You should see an Error message since both apk's are active)
- deactivate old apk (You should not see the Error message anymore)
- hit "Save"
- If this is a beta 1, go to "Product Details" tab -> Recent Changes, change the url to http://www.mozilla.com/en-US/mobile/{VERSION}beta/releasenotes/
- and hit "Save"
Push XULRunner to Mirrors
Update XULRunner wiki page
For major releases or chemspills, update the links on:
Also for older releases:
- https://developer.mozilla.org/en/XULRunner_1.9.2_Release_Notes
- https://developer.mozilla.org/en/Gecko_SDK
Check Throttling
See http://update-watch.localgho.st/release/ for example AUS links
Some links to check:
- Automatic (idle time check) update links:
- Manual update links:
Push to Release Channel (for beta releases and release releases)
Once there is enough uptake and we get "go" from release driver.
Update symlinks
Once we're signed off on the release channel.
Remove index.html files
If you created them earlier to hide the release.