Difference between revisions of "Releases:Branch Tag Build Release"

From Camino Wiki
Jump to navigation Jump to search
(→‎Check out the source: Identify build team's new branch scheme)
Line 14: Line 14:
  
 
If you’re making a release that corresponds to a Gecko “final” version, be sure to pick up source that doesn’t have a “prerelease” Gecko version number in [http://lxr.mozilla.org/mozilla/source/config/milestone.txt <code>config/milestone.txt</code>].  Release tags are good for this, but branch snapshots taken at a known freeze time can work too in a pinch.
 
If you’re making a release that corresponds to a Gecko “final” version, be sure to pick up source that doesn’t have a “prerelease” Gecko version number in [http://lxr.mozilla.org/mozilla/source/config/milestone.txt <code>config/milestone.txt</code>].  Release tags are good for this, but branch snapshots taken at a known freeze time can work too in a pinch.
 +
 +
As of the Gecko 1.8.1.4 and 1.8.0.11 releases, it is possible to base a Camino version on a Gecko release branch forked by the build team.  Camino 1.5 is based on <code>GECKO181_20070501_RELBRANCH</code>, for example, the release branch for products based on Gecko 1.8.1.4 (Firefox 2.0.0.4).
  
 
  cvs checkout -r FIREFOX_1_5_0_10_RELEASE mozilla/client.mk mozilla/camino/config
 
  cvs checkout -r FIREFOX_1_5_0_10_RELEASE mozilla/client.mk mozilla/camino/config

Revision as of 11:45, 1 May 2007

How to (branch and tag and build and) release a new version of Camino
by Mark Mentovai
on 2007-02-28

Pinkerton keeps rooting for me to get hit by a bus. I’ve had pretty good luck so far, in large part because I’ve abandoned my old habit of running after buses while they’re in motion and banging on the doors, but even so, the specifics of our release procedure probably should be documented.

These instructions correspond to Camino 1.0.4 (Gecko 1.8.0.10). The base tag for this release was FIREFOX_1_5_0_10_RELEASE. This specifies the apex of the minibranch. For the 1.0.4 release, changes to that tag for Camino were made on a new CAMINO_1_0_4_MINIBRANCH branch, and the release tag was CAMINO_1_0_4_RELEASE. Camino branch and release tags follow this convention (CAMINO_1_1_A2_MINIBRANCH, CAMINO_1_1_B_RELEASE).

Check out the source

Instead of a tag, you can also use a branch name, or a branch name with a date. If using a branch name and a date, use -D when checking out client.mk, and set MOZ_CO_DATE when making client.mk’s checkout target.

If you’re making a release that corresponds to a Gecko “final” version, be sure to pick up source that doesn’t have a “prerelease” Gecko version number in config/milestone.txt. Release tags are good for this, but branch snapshots taken at a known freeze time can work too in a pinch.

As of the Gecko 1.8.1.4 and 1.8.0.11 releases, it is possible to base a Camino version on a Gecko release branch forked by the build team. Camino 1.5 is based on GECKO181_20070501_RELBRANCH, for example, the release branch for products based on Gecko 1.8.1.4 (Firefox 2.0.0.4).

cvs checkout -r FIREFOX_1_5_0_10_RELEASE mozilla/client.mk mozilla/camino/config
cd mozilla
MOZCONFIG=`pwd`/camino/config/mozconfig make -w -f client.mk checkout

Fork a minibranch

This can be done either by branching the entire checked-out tree, or branching individual files as needed. client.mk always need to be minibranched to adjust its tags. I tend to branch the entire tree if any other files need to change, and to only branch client.mk if that’s all that’s changing. After branching, use cvs update to change the tag on the files you’ll be working on in your working copy, so that changes will be committed to the right branch. The usage here branches everything rooted at the current working directory (mozilla). To branch only individual files, add their paths to the command lines.

cvs tag -b CAMINO_1_0_4_MINIBRANCH
cvs update -r CAMINO_1_0_4_MINIBRANCH

Fix your (my) mistakes

At this point, I realized that the FIREFOX_1_5_0_10_RELEASE tag didn’t include changes to two Camino files that had been made recently on the MOZILLA_1_8_0_BRANCH in anticipation of Camino 1.0.4. I realized this because the release notes were missing. I found the other file by querying Bonsai. Here, I updated my local copies of these files to the current 1.8.0 branch versions, and then set the branch tag. I had to use cvs tag -B -F to move the tag because ad_blocking.css had already been branched. cvs tag -B -F is dangerous, but I know what I’m doing. Next time, I’ll remember to check this kind of thing before forking the minibranch.

cvs update -r MOZILLA_1_8_0_BRANCH \
  camino/resources/application/ad_blocking.css \
  camino/docs/Release\ Notes\ 1-0-4.rtf
cvs tag -B -F -b CAMINO_1_0_4_MINIBRANCH \
  camino/resources/application/ad_blocking.css \
  camino/docs/Release\ Notes\ 1-0-4.rtf
cvs update -r CAMINO_1_0_4_MINIBRANCH \
  camino/resources/application/ad_blocking.css \
  camino/docs/Release\ Notes\ 1-0-4.rtf

Make client.mk apply to the release tag

Now it’s possible to make changes to the working copy. First, update client.mk so that it will pull from the release tag (soon to be created). The relevant section of client.mk should look something like this. In this case, sed won’t change the NSPR and NSS tags to checked out, but that’s all right, because they’re static tags. I used to change those too, but now I think it’s clearer to see which NSPR and NSS releases were used by leaving their original tags intact in client.mk. An obvious exception applies when NSPR or NSS files need to change on the minibranch. Note that I feel entitled to use BS in the more administrative commit messages on my own private minibranch.

sed -e s/FIREFOX_1_5_0_10_RELEASE/CAMINO_1_0_4_RELEASE/ \
  < client.mk > client.mk.new && \
  mv client.mk.new client.mk
cvs commit -m The 1.0.4 minibranch is now boarding at gate 1.8.0.10" \
  client.mk

Land other changes on the minibranch

I usually find these by querying Bugzilla for bugs with text like camino-1.0.3 in the status whiteboard field, by checking Bonsai for changes I made to the last release minibranch, or by asking Smokey or Sam. Those guys remember everything. These two things come from bugs 325765 and 325964. When landing things on the minibranch, don’t forget to update the status whiteboard fields of the relevant bugs with text like [camino-1.0.4].

sed -e s/0x00010006/0x00010008/ \
  < netwerk/cache/src/nsDiskCache.h > netwerk/cache/src/nsDiskCache.h.new && \
  mv netwerk/cache/src/nsDiskCache.h.new netwerk/cache/src/nsDiskCache.h
cvs commit -m "325765 Camino 1.0 versioned its cache as 1.8 while the main 1.8.0 branch versions it as 1.6.  \
               Use 1.8 to avoid dumping established caches on upgrading from an earlier 1.0.x Camino." \
  netwerk/cache/src/nsDiskCache.h

patch -p1 < ../mathmlprompt.diff
cvs commit -m "325964 MathML missing font dialog contains extra space.  \
               Patch by Smokey Ardisson <alqahira@mindspring.com>.  r=me sr=rbs" \
  layout/mathml/base/src/mathfont.properties

Release checklist

Run the release checklist in camino/docs/ReleaseChecklist.txt to update all of the version numbers. Then, check it all in. The release checklist and the set of files it modifies may vary slightly by branch.

cat camino/docs/ReleaseChecklist.txt
cd camino
cvs commit -m "Camino 104, position and hold" \
  Info-Camino.plist \
  Info-CaminoStatic.plist \
  installer/Makefile.in \
  resources/application/ChimeraVersion.r \
  resources/application/WebsiteDefaults.strings \
  resources/application/all-camino.js \
  resources/localized/English.lproj/InfoPlist.strings
cd ..

You also might want to update the version numbers on the parent branch (MOZILLA_1_8_0_BRANCH in this case) to indicate that the branch has advanced beyond the new release. This time, I updated the above files on the parent branch to give a version number of 1.0.4+. You don’t have to do this now, it can wait until more pressing tasks are done.

Tag it

We’re set. Now tag the tree with the release tag, so that client.mk actually makes sense. Regardless of whether the whole tree or just a few files were forked on the minibranch, we always tag the entire tree needed for a Camino build, even NSPR and NSS. (We don’t need to tag all of Mozilla’s repository, it’s sufficient to tag a full Camino checkout.)

cvs tag CAMINO_1_0_4_RELEASE

If someone pulls client.mk by the CAMINO_1_0_4_RELEASE tag, then they’ll get what they expect. Change the tags in client.mk on the minibranch to correspond to the minibranch instead of the release tag. It doesn’t make much of a difference because the new minibranch is a stub-ended branch and the buck stops here, but I’m something of an anal release-master. (Observe how carefully I placed that hyphen.)

sed -e s/CAMINO_1_0_4_RELEASE/CAMINO_1_0_4_MINIBRANCH/ \
  < client.mk > client.mk.new && \
  mv client.mk.new client.mk
cvs commit -m "Please remain seated until your release-master has turned off the fasten seat belt sign." \
  client.mk

Now, this part is crappy and top-secret. We need to tag the Talkback tree too, so that tinderbox gets the right stuff. And we’ve only got access to that from the tinderbox itself. I’m not going to tell you what to use for $CVSROOT, but you can find it in the build log from any true clobber nightly produced by tinderbox.

CVSROOT=something CVS_RSH=ssh \
  cvs checkout -r MOZILLA_1_8_0_BRANCH talkback/fullsoft
CVSROOT=something CVS_RSH=ssh \
  cvs tag -b CAMINO_1_0_4_MINIBRANCH talkback/fullsoft
CVSROOT=something CVS_RSH=ssh \
  cvs update -r CAMINO_1_0_4_MINIBRANCH talkback/fullsoft
CVSROOT=something CVS_RSH=ssh \
  cvs tag CAMINO_1_0_4_RELEASE talkback/fullsoft

Make Tinderbox build it

Everything’s set now. Configure tinderbox to produce a new build from the release tag. This is a pain, too, but fortunately, the previous release can be used as a template. The stupid wildcard in the rsync is to avoid copying the whole source and object trees, which have names beginning with Darwin with a capital D. Everything else important has a name beginning with a lowercase letter. rsync is used to preserve symbolic links, of which there are many.

cd /builds/tinderbox
mkdir Cm1.0.4
rsync -av Cm1.0.3/[a-z]* Cm1.0.4
sed -e s/1\\.0\\.3/1.0.4/ -e s/1_0_3/1_0_4/ \
  < Cm1.0.4/tinder-config.pl > Cm1.0.4/tinder-config.pl.new && \
  mv Cm1.0.4/tinder-config.pl.new Cm1.0.4/tinder-config.pl

It’s possible for tinderbox to build from either a branch or a tag. The right way is to build releases from tags, but if you’re sure that a tag corresponds exactly to a branch, you can cheat and build from the branch instead. I usually cheat, but for the purposes of these instructions, I’m doing it the right way. First, check $BuildTag in tinder-config.pl to make sure it corresponds to your chosen release tag (or branch). When building from a tag (instead of a branch), pull-by-timestamp (cvs checkout -D) must be turned off. It’s useful when building from branches. Its behavior is controlled by the $UseTimeStamp tinderbox configuration variable. This time, I’m using:

$BuildTag = 'CAMINO_1_0_4_RELEASE';
$UseTimeStamp      = 0;      # Use the CVS 'pull-by-timestamp' option, or not

Now, edit multi-tinderbox’ config so that it knows to build the release. Since we don’t have much spare “room” on the tinderbox, I temporarily disable the base branch build while it’s doing a release. In this case, I’m commenting out Cm1.0-M1.8.0 and adding a Cm1.0.4 entry. Later, when the release is built, I’ll comment out Cm1.0.4 and turn Cm1.0-M1.8.0 back on. multi-tinderbox reloads its configuration when it receives a SIGHUP; when it finishes the build it’s working on, it’ll start over at the top of the list in its config. For that reason, I like to put the release build I’m doing at the top of multi-config.pl.

vi /builds/tinderbox/multi-config.pl

The relevant snippet would look something like this:

$ENV{'CVS_RSH'}='ssh';
$ENV{'TBOX_CLIENT_CVS_DIR'}='/builds/cvs/mozilla/tools/tinderbox';
$BuildSleep = 5;
$Tinderboxes = [
  { tree => "Cm1.0.4" },
#  { tree => "Cm1.0-M1.8.0" },
  { tree => "Cm1.1-M1.8" },
  { tree => "CmTrunk" },
];

And then tell multi-tinderbox to reload when the current build finishes:

kill -HUP `cat /builds/tinderbox/multi.pid`

When the release build begins, go to the Camino tinderbox page, click “Administrate Tinderbox Trees” (it should say “Administer,” but whatever), and turn on log scraping for the new build. Do it before the first build completes. If you don’t do this step, it’s no big deal, but the (hopefully green, possibly orange or red) box on tinderbox won’t show test results.

If something goes wrong, fix it. Use the tinderbox logs to your advantage. If you’ve got to move a tag or something, you can refer to the “fix-it” section above where I fixed ad_blocking.css, remembering that at this point, you’ve got both a _MINIBRANCH and _RELEASE tag to worry about.

Stage it

Once the build is done, test it. It’s not evil to get other people to help test the build with you, just pass them the URL to the “nightly” that tinderbox uploaded. If it seems reasonable, stage it and let people know. When possible, it’s nice to let the localization team know that a build is ready and give them time to prepare the multilingual version, and then stage the en-US and multilingual versions together when everything is ready.

ssh stage.mozilla.org
cd /home/ftp/pub/camino/releases
cp -p ../nightly/2007-02-28-13-1.0.4/Camino.dmg Camino-1.0.4.dmg
chmod 644 Camino-1.0.4.dmg
cp -p Camino-1.0.4.dmg en-US
rm MD5SUMS
LC_ALL=C bash
md5sum * > MD5SUMS
chmod 644 MD5SUMS
exit
exit

Stage the source tarball and the multilingual version when they’re ready, too. The source tarball will go in /home/ftp/pub/camino/source/camino-1.0.4.tar.bz2, and that directory has an MD5SUMS file as well. The multilingual release will go in /home/ftp/pub/camino/releases/Camino-1.0.4-MultiLang.dmg, with a copy at /home/ftp/pub/camino/releases/all/Camino-1.0.4.dmg.

Create a source release

We provide source tarballs for major releases (not alphas, betas, or release candidates). Check out a fresh tree using anonymous CVS, so that the CVS/Root files are correct for people bootstrapping anonymous CVS workspaces. If the .tar.bz2 file doesn’t wind up at about 33MB (for the 1.8.0 branch), something’s probably wrong.

touch ~/.cvspass
CVSROOT=:pserver:anonymous@cvs-mirror.mozilla.org:/cvsroot \
  cvs checkout -r CAMINO_1_0_4_RELEASE mozilla/client.mk mozilla/camino/config
cd mozilla
MOZCONFIG=`pwd`/camino/config/mozconfig make -w -f client.mk checkout
cd ..
chmod -R a+rX mozilla
BZIP2=-9 tar -jcf camino-1.0.4.tar.bz2 mozilla

Stage the source release as described above in Stage it.

Have someone else set up Talkback reports

Ask Jay to set up Talkback reports, at least until Breakpad is ready. Send him an e-mail with the relevant build information, like:

VendorID = "MozillaOrg"
ProductID = "Camino10"
PlatformID = "MacOSX"
BuildID = "2007022813"

You can get this information from the Contents/MacOS/components/talkback/master.ini file from Camino.app in the release you’ve built.

Other things to do

Your job as a branch tag build release-master is done. It's time to sit back, relax, and watch as other people do other things. If you needed to modify the procedure in any way, now would be an excellent time to update this document.