Camino Wiki - User contributions [en]

Releases:Branch Tag Build Release

2008-03-25T03:05:00Z

Mento: /* Other things to do */

<big>How to (branch and tag and build and) release a new version of Camino</big>
 
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 [http://www.caminobrowser.org/releases/1.0.4.php Camino 1.0.4] ([http://www.mozilla.com/en-US/firefox/releases/1.5.0.10.html Gecko 1.8.0.10]). The base tag for this release was <code>FIREFOX_1_5_0_10_RELEASE</code>. This specifies the apex of the minibranch. For the 1.0.4 release, changes to that tag for Camino were made on a new <code>CAMINO_1_0_4_MINIBRANCH</code> branch, and the release tag was <code>CAMINO_1_0_4_RELEASE</code>. Camino branch and release tags follow this convention (<code>CAMINO_1_1_A2_MINIBRANCH</code>, <code>CAMINO_1_1_B_RELEASE</code>).

== 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 <code>-D</code> when checking out <code>client.mk</code>, and set <code>MOZ_CO_DATE</code> when making <code>client.mk</code>’s <code>checkout</code> 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 [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. (KaiRo has a [http://dev.seamonkey.at/?d=x&i=mozilla&m=t tool] that periodically queries tags, or you can use <code>cvs log</code> or perhaps even [http://bonsai.mozilla.org/cvsgraph.cgi?file=/mozilla/camino/config/version.txt bonsai] (or [http://bonsai.mozilla.org/cvsgraph.cgi?file=/mozilla/camino/resources/application/all-camino.js this link] for older branches) to find relevant Gecko tags.)

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). Note that we’ve been asked not to check in to this branch, even in <code>mozilla/camino</code>, so our own minibranch (below) is still needed.

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

In some cases, it’s not proper to base a Camino release off of an entire Gecko tree. For example, Camino 1.5.1 is based on <code>FIREFOX_2_0_0_6_RELEASE</code> in all directories except for <code>mozilla/camino</code>, which is based on then-current code from <code>CAMINO_1_5_BRANCH</code>. To switch the base in <code>mozilla/camino</code>, after the initial checkout above, do:

cvs update -r CAMINO_1_5_BRANCH -Pd camino

== Fork a minibranch ==

This can be done either by branching the entire checked-out tree, or branching individual files as needed. <code>client.mk</code> always needs 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 <code>client.mk</code> if that’s all that’s changing. After branching, use <code>cvs update</code> 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 (<code>mozilla</code>).

cvs tag -b CAMINO_1_0_4_MINIBRANCH
cvs update -r CAMINO_1_0_4_MINIBRANCH

This usage only branches the individual files which will be modified from the base tag(s) for inclusion in the release tag:

cvs tag -b CAMINO_1_5_1_MINIBRANCH \
client.mk \
camino/Info-Camino.plist \
camino/Info-CaminoStatic.plist \
camino/resources/application/all-camino.js \
camino/resources/localized/English.lproj/InfoPlist.strings
cvs update -r CAMINO_1_5_1_MINIBRANCH \
client.mk \
camino/Info-Camino.plist \
camino/Info-CaminoStatic.plist \
camino/resources/application/all-camino.js \
camino/resources/localized/English.lproj/InfoPlist.strings

With recent branches, it is often only necessary to minibranch <code>client.mk</code> and the Camino version file:

cvs tag -b CAMINO_1_6_B3_MINIBRANCH client.mk camino/config/version.txt
cvs update -r CAMINO_1_6_B3_MINIBRANCH client.mk camino/config/version.txt

Note that in some cases, a minibranch will be reused for an emergency release. For example, <code>CAMINO_1_6_B1_MINIBRANCH</code> was used for both Camino 1.6b1 and the emergency followup release, 1.6b2. With such a release, you should simply check out a copy of the minibranch and then skip to the [[#Land other changes on the minibranch|land changes]] section to update it as needed.

== Fix your (my) mistakes ==

At this point, I realized that the <code>FIREFOX_1_5_0_10_RELEASE</code> tag didn’t include changes to two Camino files that had been made recently on the <code>MOZILLA_1_8_0_BRANCH</code> in anticipation of Camino 1.0.4. I realized this because the release notes were missing. I found the other file by querying [http://bonsai.mozilla.org/ 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 <code>cvs tag -B -F</code> to move the tag because <code>ad_blocking.css</code> had already been branched. <code>cvs tag -B -F</code> 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 <code>client.mk</code> apply to the release tag ==

Now it’s possible to make changes to the working copy. First, update <code>client.mk</code> so that it will pull from the release tag (soon to be created). The relevant section of <code>client.mk</code> should look something like [http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/client.mk&rev=CAMINO_1_0_4_RELEASE&mark=241-245#236 this]. In this case, <code>sed</code> 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 <code>client.mk</code>. 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 [https://bugzilla.mozilla.org/buglist.cgi?status_whiteboard_type=substring&status_whiteboard=camino-1.0.3 querying Bugzilla for bugs with text like <code>camino-1.0.3</code>] in the status whiteboard field, by [http://bonsai.mozilla.org/cvsquery.cgi?branch=CAMINO_1_0_3_MINIBRANCH&date=all checking Bonsai for changes I made to the last release minibranch], or by asking [[User:Sardisson|Smokey]] or [[User:Admin|Sam]]. Those guys remember everything. These two things come from bugs [https://bugzilla.mozilla.org/show_bug.cgi?id=325765 325765] and [https://bugzilla.mozilla.org/show_bug.cgi?id=325964 325964]. When landing things on the minibranch, don’t forget to update the status whiteboard fields of the relevant bugs with text like <code>[camino-1.0.4]</code>.

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

With recent branches, often the only change after the <code>client.mk</code> change is to update the Camino version file:

echo 1.6b3 > camino/config/version.txt
cvs commit -m "Numbers for Camino 1.6b3" client.mk camino/config/version.txt

== Release checklist ==

Run the release checklist in [http://lxr.mozilla.org/mozilla/source/camino/docs/ReleaseChecklist.txt <code>camino/docs/ReleaseChecklist.txt</code>] 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 ..

On recent branches, if you’ve been following this guide, by the time you run the release checklist, there shouldn’t be any actual work to do. It should be a simple verification that the source tree is ready for a release.

You also might want to update the version numbers on the parent branch (<code>MOZILLA_1_8_0_BRANCH</code> 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+, but this versioning scheme is deprecated. Under the new scheme, the version number should be updated the the next version expected to be released from the branch, with “pre” appended. In this example, the version would be updated to 1.0.5pre. 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 <code>client.mk</code> 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 <code>client.mk</code> by the <code>CAMINO_1_0_4_RELEASE</code> tag, then they’ll get what they expect. Change the tags in <code>client.mk</code> 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.) This is only recommended if the entire tree was forked to make a minibranch, otherwise, it’s pointless. If using a Gecko or Firefox release branch (recommended), you probably won’t have forked the entire tree for a minibranch, so this step is safe to skip.

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 used to be crappy and top-secret, and fortunately, it’s no longer necessary now that tinderbox can use <code>$UsePrebuiltTalkback</code>. The old procedure is included here to confuse you. We used to need to tag the Talkback tree too, so that tinderbox would get the right stuff. We only had access to that from the tinderbox itself. I’m not going to tell you what we used for <code>$CVSROOT</code>, but you could have found 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 <code>$BuildTag</code> in <code>tinder-config.pl</code> to make sure it corresponds to your chosen release tag (or branch). When building from a tag (instead of a branch), pull-by-timestamp (<code>cvs checkout -D</code>) must be turned off. It’s useful when building from branches. Its behavior is controlled by the <code>$UseTimeStamp</code> 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

Other significant variables affect the name displayed on the tinderbox status page, and the names of the directories created on the FTP server:

$BuildNameExtra = 'Cm1.0.4';
$milestone = "1.0.4";

Now, edit <code>multi-tinderbox</code>’ 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 <code>Cm1.0-M1.8.0</code> and adding a <code>Cm1.0.4</code> entry. Later, when the release is built, I’ll comment out <code>Cm1.0.4</code> and turn <code>Cm1.0-M1.8.0</code> back on. <code>multi-tinderbox</code> reloads its configuration when it receives a <code>SIGHUP</code>; 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 <code>multi-config.pl</code>.

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 <code>multi-tinderbox</code> to reload when the current build finishes:

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

When the release build begins, go to the [http://tinderbox.mozilla.org/Camino/ Camino tinderbox page], click “[http://tinderbox.mozilla.org/admintree.cgi?tree=Camino 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 your (my) mistakes|“fix-it”]] section above where I fixed <code>ad_blocking.css</code>, remembering that at this point, you’ve got both a <code>_MINIBRANCH</code> and <code>_RELEASE</code> 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 “[http://ftp.mozilla.org/pub/mozilla.org/camino/nightly/ nightly]” that tinderbox uploaded. If it seems reasonable, stage it and let people know. When possible, it’s nice to let the [http://caminol10n.mozdev.org/ 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 <code>/home/ftp/pub/camino/source/camino-1.0.4.tar.bz2</code>, and that directory has an <code>MD5SUMS</code> file as well. The multilingual release will go in
<code>/home/ftp/pub/camino/releases/Camino-1.0.4-MultiLang.dmg</code>, with a copy at <code>/home/ftp/pub/camino/releases/all/Camino-1.0.4.dmg</code>.

== Create a source release ==

We provide [http://ftp.mozilla.org/pub/mozilla.org/camino/source/ source tarballs] for major releases (not alphas, betas, or release candidates). Check out a fresh tree using anonymous CVS, so that the <code>CVS/Root</code> files are correct for people bootstrapping anonymous CVS workspaces. If the <code>.tar.bz2</code> 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
rm .mozconfig.mk .mozconfig.out
cd ..
chmod -R a+rX mozilla
BZIP2=-9 tar --owner 0 --group 0 -jcf camino-1.0.4.tar.bz2 mozilla

Stage the source release as described above in [[#Stage it|Stage it]].

== Have someone else set up Talkback reports ==

Ask Sam to set up [http://talkback-public.mozilla.org/reports/camino/ Talkback reports], at least until [http://code.google.com/p/google-breakpad/ 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 <code>Contents/MacOS/components/talkback/master.ini</code> file from <code>Camino.app</code> 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.

* Wait for mirror propagation from <code>stage.mozilla.org</code> to all of the systems handling <code>releases.mozilla.org</code>, <code>ftp.mozilla.org</code>, and other mirrors.
* Have someone on the build team update bouncer. [https://bugzilla.mozilla.org/enter_bug.cgi?product=mozilla.org&component=Build%20%26%20Release File a bug in the “mozilla.org:Build & Release” component], or e-mail [mailto:build@mozilla.org build@mozilla.org]. If you forget how to accomplish this step, ask Reed. He’s always happy to remind us.
* Someone’s got to [[Releases:Website Checklist|update the website]], the web site, or both.
* Some releases include a “release notes” URL that needs to be populated with content or a redirect. The release notes URL is defined as <code>ReleaseNotesDefault</code> in [http://lxr.mozilla.org/mozilla1.8.0/source/camino/resources/application/WebsiteDefaults.strings <code>camino/resources/application/WebsiteDefaults.strings</code>] and is updated as part of the [[#Release checklist|release checklist]]. The URL used in Camino 1.0.4 is [http://www.mozilla.org/products/camino/releases/1.0.4.html], which redirects to [http://www.caminobrowser.org/releases/1.0.4.php].
* Don’t forget to restore the Tinderbox configuration in <code>multi-config.pl</code> and force <code>multi-tinderbox</code> to reload its configuration with <code>SIGHUP</code>, as described in the [[#Make Tinderbox build it|Make Tinderbox build it]] section.

Releases:Branch Tag Build Release

2008-03-25T03:04:26Z

Mento: /* Other things to do */ Note to not forget to restore multi-config.pl

<big>How to (branch and tag and build and) release a new version of Camino</big>
 
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 [http://www.caminobrowser.org/releases/1.0.4.php Camino 1.0.4] ([http://www.mozilla.com/en-US/firefox/releases/1.5.0.10.html Gecko 1.8.0.10]). The base tag for this release was <code>FIREFOX_1_5_0_10_RELEASE</code>. This specifies the apex of the minibranch. For the 1.0.4 release, changes to that tag for Camino were made on a new <code>CAMINO_1_0_4_MINIBRANCH</code> branch, and the release tag was <code>CAMINO_1_0_4_RELEASE</code>. Camino branch and release tags follow this convention (<code>CAMINO_1_1_A2_MINIBRANCH</code>, <code>CAMINO_1_1_B_RELEASE</code>).

== 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 <code>-D</code> when checking out <code>client.mk</code>, and set <code>MOZ_CO_DATE</code> when making <code>client.mk</code>’s <code>checkout</code> 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 [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. (KaiRo has a [http://dev.seamonkey.at/?d=x&i=mozilla&m=t tool] that periodically queries tags, or you can use <code>cvs log</code> or perhaps even [http://bonsai.mozilla.org/cvsgraph.cgi?file=/mozilla/camino/config/version.txt bonsai] (or [http://bonsai.mozilla.org/cvsgraph.cgi?file=/mozilla/camino/resources/application/all-camino.js this link] for older branches) to find relevant Gecko tags.)

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). Note that we’ve been asked not to check in to this branch, even in <code>mozilla/camino</code>, so our own minibranch (below) is still needed.

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

In some cases, it’s not proper to base a Camino release off of an entire Gecko tree. For example, Camino 1.5.1 is based on <code>FIREFOX_2_0_0_6_RELEASE</code> in all directories except for <code>mozilla/camino</code>, which is based on then-current code from <code>CAMINO_1_5_BRANCH</code>. To switch the base in <code>mozilla/camino</code>, after the initial checkout above, do:

cvs update -r CAMINO_1_5_BRANCH -Pd camino

== Fork a minibranch ==

This can be done either by branching the entire checked-out tree, or branching individual files as needed. <code>client.mk</code> always needs 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 <code>client.mk</code> if that’s all that’s changing. After branching, use <code>cvs update</code> 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 (<code>mozilla</code>).

cvs tag -b CAMINO_1_0_4_MINIBRANCH
cvs update -r CAMINO_1_0_4_MINIBRANCH

This usage only branches the individual files which will be modified from the base tag(s) for inclusion in the release tag:

cvs tag -b CAMINO_1_5_1_MINIBRANCH \
client.mk \
camino/Info-Camino.plist \
camino/Info-CaminoStatic.plist \
camino/resources/application/all-camino.js \
camino/resources/localized/English.lproj/InfoPlist.strings
cvs update -r CAMINO_1_5_1_MINIBRANCH \
client.mk \
camino/Info-Camino.plist \
camino/Info-CaminoStatic.plist \
camino/resources/application/all-camino.js \
camino/resources/localized/English.lproj/InfoPlist.strings

With recent branches, it is often only necessary to minibranch <code>client.mk</code> and the Camino version file:

cvs tag -b CAMINO_1_6_B3_MINIBRANCH client.mk camino/config/version.txt
cvs update -r CAMINO_1_6_B3_MINIBRANCH client.mk camino/config/version.txt

Note that in some cases, a minibranch will be reused for an emergency release. For example, <code>CAMINO_1_6_B1_MINIBRANCH</code> was used for both Camino 1.6b1 and the emergency followup release, 1.6b2. With such a release, you should simply check out a copy of the minibranch and then skip to the [[#Land other changes on the minibranch|land changes]] section to update it as needed.

== Fix your (my) mistakes ==

At this point, I realized that the <code>FIREFOX_1_5_0_10_RELEASE</code> tag didn’t include changes to two Camino files that had been made recently on the <code>MOZILLA_1_8_0_BRANCH</code> in anticipation of Camino 1.0.4. I realized this because the release notes were missing. I found the other file by querying [http://bonsai.mozilla.org/ 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 <code>cvs tag -B -F</code> to move the tag because <code>ad_blocking.css</code> had already been branched. <code>cvs tag -B -F</code> 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 <code>client.mk</code> apply to the release tag ==

Now it’s possible to make changes to the working copy. First, update <code>client.mk</code> so that it will pull from the release tag (soon to be created). The relevant section of <code>client.mk</code> should look something like [http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/client.mk&rev=CAMINO_1_0_4_RELEASE&mark=241-245#236 this]. In this case, <code>sed</code> 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 <code>client.mk</code>. 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 [https://bugzilla.mozilla.org/buglist.cgi?status_whiteboard_type=substring&status_whiteboard=camino-1.0.3 querying Bugzilla for bugs with text like <code>camino-1.0.3</code>] in the status whiteboard field, by [http://bonsai.mozilla.org/cvsquery.cgi?branch=CAMINO_1_0_3_MINIBRANCH&date=all checking Bonsai for changes I made to the last release minibranch], or by asking [[User:Sardisson|Smokey]] or [[User:Admin|Sam]]. Those guys remember everything. These two things come from bugs [https://bugzilla.mozilla.org/show_bug.cgi?id=325765 325765] and [https://bugzilla.mozilla.org/show_bug.cgi?id=325964 325964]. When landing things on the minibranch, don’t forget to update the status whiteboard fields of the relevant bugs with text like <code>[camino-1.0.4]</code>.

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

With recent branches, often the only change after the <code>client.mk</code> change is to update the Camino version file:

echo 1.6b3 > camino/config/version.txt
cvs commit -m "Numbers for Camino 1.6b3" client.mk camino/config/version.txt

== Release checklist ==

Run the release checklist in [http://lxr.mozilla.org/mozilla/source/camino/docs/ReleaseChecklist.txt <code>camino/docs/ReleaseChecklist.txt</code>] 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 ..

On recent branches, if you’ve been following this guide, by the time you run the release checklist, there shouldn’t be any actual work to do. It should be a simple verification that the source tree is ready for a release.

You also might want to update the version numbers on the parent branch (<code>MOZILLA_1_8_0_BRANCH</code> 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+, but this versioning scheme is deprecated. Under the new scheme, the version number should be updated the the next version expected to be released from the branch, with “pre” appended. In this example, the version would be updated to 1.0.5pre. 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 <code>client.mk</code> 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 <code>client.mk</code> by the <code>CAMINO_1_0_4_RELEASE</code> tag, then they’ll get what they expect. Change the tags in <code>client.mk</code> 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.) This is only recommended if the entire tree was forked to make a minibranch, otherwise, it’s pointless. If using a Gecko or Firefox release branch (recommended), you probably won’t have forked the entire tree for a minibranch, so this step is safe to skip.

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 used to be crappy and top-secret, and fortunately, it’s no longer necessary now that tinderbox can use <code>$UsePrebuiltTalkback</code>. The old procedure is included here to confuse you. We used to need to tag the Talkback tree too, so that tinderbox would get the right stuff. We only had access to that from the tinderbox itself. I’m not going to tell you what we used for <code>$CVSROOT</code>, but you could have found 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 <code>$BuildTag</code> in <code>tinder-config.pl</code> to make sure it corresponds to your chosen release tag (or branch). When building from a tag (instead of a branch), pull-by-timestamp (<code>cvs checkout -D</code>) must be turned off. It’s useful when building from branches. Its behavior is controlled by the <code>$UseTimeStamp</code> 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

Other significant variables affect the name displayed on the tinderbox status page, and the names of the directories created on the FTP server:

$BuildNameExtra = 'Cm1.0.4';
$milestone = "1.0.4";

Now, edit <code>multi-tinderbox</code>’ 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 <code>Cm1.0-M1.8.0</code> and adding a <code>Cm1.0.4</code> entry. Later, when the release is built, I’ll comment out <code>Cm1.0.4</code> and turn <code>Cm1.0-M1.8.0</code> back on. <code>multi-tinderbox</code> reloads its configuration when it receives a <code>SIGHUP</code>; 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 <code>multi-config.pl</code>.

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 <code>multi-tinderbox</code> to reload when the current build finishes:

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

When the release build begins, go to the [http://tinderbox.mozilla.org/Camino/ Camino tinderbox page], click “[http://tinderbox.mozilla.org/admintree.cgi?tree=Camino 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 your (my) mistakes|“fix-it”]] section above where I fixed <code>ad_blocking.css</code>, remembering that at this point, you’ve got both a <code>_MINIBRANCH</code> and <code>_RELEASE</code> 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 “[http://ftp.mozilla.org/pub/mozilla.org/camino/nightly/ nightly]” that tinderbox uploaded. If it seems reasonable, stage it and let people know. When possible, it’s nice to let the [http://caminol10n.mozdev.org/ 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 <code>/home/ftp/pub/camino/source/camino-1.0.4.tar.bz2</code>, and that directory has an <code>MD5SUMS</code> file as well. The multilingual release will go in
<code>/home/ftp/pub/camino/releases/Camino-1.0.4-MultiLang.dmg</code>, with a copy at <code>/home/ftp/pub/camino/releases/all/Camino-1.0.4.dmg</code>.

== Create a source release ==

We provide [http://ftp.mozilla.org/pub/mozilla.org/camino/source/ source tarballs] for major releases (not alphas, betas, or release candidates). Check out a fresh tree using anonymous CVS, so that the <code>CVS/Root</code> files are correct for people bootstrapping anonymous CVS workspaces. If the <code>.tar.bz2</code> 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
rm .mozconfig.mk .mozconfig.out
cd ..
chmod -R a+rX mozilla
BZIP2=-9 tar --owner 0 --group 0 -jcf camino-1.0.4.tar.bz2 mozilla

Stage the source release as described above in [[#Stage it|Stage it]].

== Have someone else set up Talkback reports ==

Ask Sam to set up [http://talkback-public.mozilla.org/reports/camino/ Talkback reports], at least until [http://code.google.com/p/google-breakpad/ 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 <code>Contents/MacOS/components/talkback/master.ini</code> file from <code>Camino.app</code> 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.

* Wait for mirror propagation from <code>stage.mozilla.org</code> to all of the systems handling <code>releases.mozilla.org</code>, <code>ftp.mozilla.org</code>, and other mirrors.
* Have someone on the build team update bouncer. [https://bugzilla.mozilla.org/enter_bug.cgi?product=mozilla.org&component=Build%20%26%20Release File a bug in the “mozilla.org:Build & Release” component], or e-mail [mailto:build@mozilla.org build@mozilla.org]. If you forget how to accomplish this step, ask Reed. He’s always happy to remind us.
* Someone’s got to [[Releases:Website Checklist|update the website]], the web site, or both.
* Some releases include a “release notes” URL that needs to be populated with content or a redirect. The release notes URL is defined as <code>ReleaseNotesDefault</code> in [http://lxr.mozilla.org/mozilla1.8.0/source/camino/resources/application/WebsiteDefaults.strings <code>camino/resources/application/WebsiteDefaults.strings</code>] and is updated as part of the [[#Release checklist|release checklist]]. The URL used in Camino 1.0.4 is [http://www.mozilla.org/products/camino/releases/1.0.4.html], which redirects to [http://www.caminobrowser.org/releases/1.0.4.php].
* Don’t forget to restore the Tinderbox configuration in <code>multi-config.pl</code>, as described in the [[#Make Tinderbox build it]] section.

Releases:Branch Tag Build Release

2008-03-25T03:00:33Z

Mento: /* Tag it */

Releases:Branch Tag Build Release

2008-03-25T02:58:16Z

Mento: /* Fork a minibranch */ Note reuse of minibranch

<big>How to (branch and tag and build and) release a new version of Camino</big>
 
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 [http://www.caminobrowser.org/releases/1.0.4.php Camino 1.0.4] ([http://www.mozilla.com/en-US/firefox/releases/1.5.0.10.html Gecko 1.8.0.10]). The base tag for this release was <code>FIREFOX_1_5_0_10_RELEASE</code>. This specifies the apex of the minibranch. For the 1.0.4 release, changes to that tag for Camino were made on a new <code>CAMINO_1_0_4_MINIBRANCH</code> branch, and the release tag was <code>CAMINO_1_0_4_RELEASE</code>. Camino branch and release tags follow this convention (<code>CAMINO_1_1_A2_MINIBRANCH</code>, <code>CAMINO_1_1_B_RELEASE</code>).

== 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 <code>-D</code> when checking out <code>client.mk</code>, and set <code>MOZ_CO_DATE</code> when making <code>client.mk</code>’s <code>checkout</code> 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 [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. (KaiRo has a [http://dev.seamonkey.at/?d=x&i=mozilla&m=t tool] that periodically queries tags, or you can use <code>cvs log</code> or perhaps even [http://bonsai.mozilla.org/cvsgraph.cgi?file=/mozilla/camino/config/version.txt bonsai] (or [http://bonsai.mozilla.org/cvsgraph.cgi?file=/mozilla/camino/resources/application/all-camino.js this link] for older branches) to find relevant Gecko tags.)

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). Note that we’ve been asked not to check in to this branch, even in <code>mozilla/camino</code>, so our own minibranch (below) is still needed.

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

In some cases, it’s not proper to base a Camino release off of an entire Gecko tree. For example, Camino 1.5.1 is based on <code>FIREFOX_2_0_0_6_RELEASE</code> in all directories except for <code>mozilla/camino</code>, which is based on then-current code from <code>CAMINO_1_5_BRANCH</code>. To switch the base in <code>mozilla/camino</code>, after the initial checkout above, do:

cvs update -r CAMINO_1_5_BRANCH -Pd camino

== Fork a minibranch ==

This can be done either by branching the entire checked-out tree, or branching individual files as needed. <code>client.mk</code> always needs 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 <code>client.mk</code> if that’s all that’s changing. After branching, use <code>cvs update</code> 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 (<code>mozilla</code>).

cvs tag -b CAMINO_1_0_4_MINIBRANCH
cvs update -r CAMINO_1_0_4_MINIBRANCH

This usage only branches the individual files which will be modified from the base tag(s) for inclusion in the release tag:

cvs tag -b CAMINO_1_5_1_MINIBRANCH \
client.mk \
camino/Info-Camino.plist \
camino/Info-CaminoStatic.plist \
camino/resources/application/all-camino.js \
camino/resources/localized/English.lproj/InfoPlist.strings
cvs update -r CAMINO_1_5_1_MINIBRANCH \
client.mk \
camino/Info-Camino.plist \
camino/Info-CaminoStatic.plist \
camino/resources/application/all-camino.js \
camino/resources/localized/English.lproj/InfoPlist.strings

With recent branches, it is often only necessary to minibranch <code>client.mk</code> and the Camino version file:

cvs tag -b CAMINO_1_6_B3_MINIBRANCH client.mk camino/config/version.txt
cvs update -r CAMINO_1_6_B3_MINIBRANCH client.mk camino/config/version.txt

Note that in some cases, a minibranch will be reused for an emergency release. For example, <code>CAMINO_1_6_B1_MINIBRANCH</code> was used for both Camino 1.6b1 and the emergency followup release, 1.6b2. With such a release, you should simply check out a copy of the minibranch and then skip to the [[#Land other changes on the minibranch|land changes]] section to update it as needed.

== Fix your (my) mistakes ==

At this point, I realized that the <code>FIREFOX_1_5_0_10_RELEASE</code> tag didn’t include changes to two Camino files that had been made recently on the <code>MOZILLA_1_8_0_BRANCH</code> in anticipation of Camino 1.0.4. I realized this because the release notes were missing. I found the other file by querying [http://bonsai.mozilla.org/ 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 <code>cvs tag -B -F</code> to move the tag because <code>ad_blocking.css</code> had already been branched. <code>cvs tag -B -F</code> 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 <code>client.mk</code> apply to the release tag ==

Now it’s possible to make changes to the working copy. First, update <code>client.mk</code> so that it will pull from the release tag (soon to be created). The relevant section of <code>client.mk</code> should look something like [http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/client.mk&rev=CAMINO_1_0_4_RELEASE&mark=241-245#236 this]. In this case, <code>sed</code> 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 <code>client.mk</code>. 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 [https://bugzilla.mozilla.org/buglist.cgi?status_whiteboard_type=substring&status_whiteboard=camino-1.0.3 querying Bugzilla for bugs with text like <code>camino-1.0.3</code>] in the status whiteboard field, by [http://bonsai.mozilla.org/cvsquery.cgi?branch=CAMINO_1_0_3_MINIBRANCH&date=all checking Bonsai for changes I made to the last release minibranch], or by asking [[User:Sardisson|Smokey]] or [[User:Admin|Sam]]. Those guys remember everything. These two things come from bugs [https://bugzilla.mozilla.org/show_bug.cgi?id=325765 325765] and [https://bugzilla.mozilla.org/show_bug.cgi?id=325964 325964]. When landing things on the minibranch, don’t forget to update the status whiteboard fields of the relevant bugs with text like <code>[camino-1.0.4]</code>.

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

With recent branches, often the only change after the <code>client.mk</code> change is to update the Camino version file:

echo 1.6b3 > camino/config/version.txt
cvs commit -m "Numbers for Camino 1.6b3" client.mk camino/config/version.txt

== Release checklist ==

Run the release checklist in [http://lxr.mozilla.org/mozilla/source/camino/docs/ReleaseChecklist.txt <code>camino/docs/ReleaseChecklist.txt</code>] 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 ..

On recent branches, if you’ve been following this guide, by the time you run the release checklist, there shouldn’t be any actual work to do. It should be a simple verification that the source tree is ready for a release.

You also might want to update the version numbers on the parent branch (<code>MOZILLA_1_8_0_BRANCH</code> 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+, but this versioning scheme is deprecated. Under the new scheme, the version number should be updated the the next version expected to be released from the branch, with “pre” appended. In this example, the version would be updated to 1.0.5pre. 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 <code>client.mk</code> 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 <code>client.mk</code> by the <code>CAMINO_1_0_4_RELEASE</code> tag, then they’ll get what they expect. Change the tags in <code>client.mk</code> 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.) This is only recommended if the entire tree was forked to make a minibranch, otherwise, it’s pointless. If using a Gecko release branch (recommended), you probably won’t have forked the entire tree for a minibranch, so this step is safe to skip.

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 used to be crappy and top-secret, and fortunately, it’s no longer necessary now that tinderbox can use <code>$UsePrebuiltTalkback</code>. The old procedure is included here to confuse you. We used to need to tag the Talkback tree too, so that tinderbox would get the right stuff. We only had access to that from the tinderbox itself. I’m not going to tell you what we used for <code>$CVSROOT</code>, but you could have found 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 <code>$BuildTag</code> in <code>tinder-config.pl</code> to make sure it corresponds to your chosen release tag (or branch). When building from a tag (instead of a branch), pull-by-timestamp (<code>cvs checkout -D</code>) must be turned off. It’s useful when building from branches. Its behavior is controlled by the <code>$UseTimeStamp</code> 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

Other significant variables affect the name displayed on the tinderbox status page, and the names of the directories created on the FTP server:

$BuildNameExtra = 'Cm1.0.4';
$milestone = "1.0.4";

Now, edit <code>multi-tinderbox</code>’ 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 <code>Cm1.0-M1.8.0</code> and adding a <code>Cm1.0.4</code> entry. Later, when the release is built, I’ll comment out <code>Cm1.0.4</code> and turn <code>Cm1.0-M1.8.0</code> back on. <code>multi-tinderbox</code> reloads its configuration when it receives a <code>SIGHUP</code>; 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 <code>multi-config.pl</code>.

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 <code>multi-tinderbox</code> to reload when the current build finishes:

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

When the release build begins, go to the [http://tinderbox.mozilla.org/Camino/ Camino tinderbox page], click “[http://tinderbox.mozilla.org/admintree.cgi?tree=Camino 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 your (my) mistakes|“fix-it”]] section above where I fixed <code>ad_blocking.css</code>, remembering that at this point, you’ve got both a <code>_MINIBRANCH</code> and <code>_RELEASE</code> 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 “[http://ftp.mozilla.org/pub/mozilla.org/camino/nightly/ nightly]” that tinderbox uploaded. If it seems reasonable, stage it and let people know. When possible, it’s nice to let the [http://caminol10n.mozdev.org/ 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 <code>/home/ftp/pub/camino/source/camino-1.0.4.tar.bz2</code>, and that directory has an <code>MD5SUMS</code> file as well. The multilingual release will go in
<code>/home/ftp/pub/camino/releases/Camino-1.0.4-MultiLang.dmg</code>, with a copy at <code>/home/ftp/pub/camino/releases/all/Camino-1.0.4.dmg</code>.

== Create a source release ==

We provide [http://ftp.mozilla.org/pub/mozilla.org/camino/source/ source tarballs] for major releases (not alphas, betas, or release candidates). Check out a fresh tree using anonymous CVS, so that the <code>CVS/Root</code> files are correct for people bootstrapping anonymous CVS workspaces. If the <code>.tar.bz2</code> 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
rm .mozconfig.mk .mozconfig.out
cd ..
chmod -R a+rX mozilla
BZIP2=-9 tar --owner 0 --group 0 -jcf camino-1.0.4.tar.bz2 mozilla

Stage the source release as described above in [[#Stage it|Stage it]].

== Have someone else set up Talkback reports ==

Ask Sam to set up [http://talkback-public.mozilla.org/reports/camino/ Talkback reports], at least until [http://code.google.com/p/google-breakpad/ 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 <code>Contents/MacOS/components/talkback/master.ini</code> file from <code>Camino.app</code> 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.

* Wait for mirror propagation from <code>stage.mozilla.org</code> to all of the systems handling <code>releases.mozilla.org</code>, <code>ftp.mozilla.org</code>, and other mirrors.
* Have someone on the build team update bouncer. [https://bugzilla.mozilla.org/enter_bug.cgi?product=mozilla.org&component=Build%20%26%20Release File a bug in the “mozilla.org:Build & Release” component], or e-mail [mailto:build@mozilla.org build@mozilla.org]. If you forget how to accomplish this step, ask Reed. He’s always happy to remind us.
* Someone’s got to [[Releases:Website Checklist|update the website]], the web site, or both.
* Some releases include a “release notes” URL that needs to be populated with content or a redirect. The release notes URL is defined as <code>ReleaseNotesDefault</code> in [http://lxr.mozilla.org/mozilla1.8.0/source/camino/resources/application/WebsiteDefaults.strings <code>camino/resources/application/WebsiteDefaults.strings</code>] and is updated as part of the [[#Release checklist|release checklist]]. The URL used in Camino 1.0.4 is [http://www.mozilla.org/products/camino/releases/1.0.4.html], which redirects to [http://www.caminobrowser.org/releases/1.0.4.php].

Releases:Branch Tag Build Release

2008-03-25T02:54:32Z

Mento: /* Release checklist */

<big>How to (branch and tag and build and) release a new version of Camino</big>
 
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 [http://www.caminobrowser.org/releases/1.0.4.php Camino 1.0.4] ([http://www.mozilla.com/en-US/firefox/releases/1.5.0.10.html Gecko 1.8.0.10]). The base tag for this release was <code>FIREFOX_1_5_0_10_RELEASE</code>. This specifies the apex of the minibranch. For the 1.0.4 release, changes to that tag for Camino were made on a new <code>CAMINO_1_0_4_MINIBRANCH</code> branch, and the release tag was <code>CAMINO_1_0_4_RELEASE</code>. Camino branch and release tags follow this convention (<code>CAMINO_1_1_A2_MINIBRANCH</code>, <code>CAMINO_1_1_B_RELEASE</code>).

== 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 <code>-D</code> when checking out <code>client.mk</code>, and set <code>MOZ_CO_DATE</code> when making <code>client.mk</code>’s <code>checkout</code> 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 [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. (KaiRo has a [http://dev.seamonkey.at/?d=x&i=mozilla&m=t tool] that periodically queries tags, or you can use <code>cvs log</code> or perhaps even [http://bonsai.mozilla.org/cvsgraph.cgi?file=/mozilla/camino/config/version.txt bonsai] (or [http://bonsai.mozilla.org/cvsgraph.cgi?file=/mozilla/camino/resources/application/all-camino.js this link] for older branches) to find relevant Gecko tags.)

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). Note that we’ve been asked not to check in to this branch, even in <code>mozilla/camino</code>, so our own minibranch (below) is still needed.

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

In some cases, it’s not proper to base a Camino release off of an entire Gecko tree. For example, Camino 1.5.1 is based on <code>FIREFOX_2_0_0_6_RELEASE</code> in all directories except for <code>mozilla/camino</code>, which is based on then-current code from <code>CAMINO_1_5_BRANCH</code>. To switch the base in <code>mozilla/camino</code>, after the initial checkout above, do:

cvs update -r CAMINO_1_5_BRANCH -Pd camino

== Fork a minibranch ==

This can be done either by branching the entire checked-out tree, or branching individual files as needed. <code>client.mk</code> always needs 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 <code>client.mk</code> if that’s all that’s changing. After branching, use <code>cvs update</code> 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 (<code>mozilla</code>).

cvs tag -b CAMINO_1_0_4_MINIBRANCH
cvs update -r CAMINO_1_0_4_MINIBRANCH

This usage only branches the individual files which will be modified from the base tag(s) for inclusion in the release tag:

cvs tag -b CAMINO_1_5_1_MINIBRANCH \
client.mk \
camino/Info-Camino.plist \
camino/Info-CaminoStatic.plist \
camino/resources/application/all-camino.js \
camino/resources/localized/English.lproj/InfoPlist.strings
cvs update -r CAMINO_1_5_1_MINIBRANCH \
client.mk \
camino/Info-Camino.plist \
camino/Info-CaminoStatic.plist \
camino/resources/application/all-camino.js \
camino/resources/localized/English.lproj/InfoPlist.strings

With recent branches, it is often only necessary to minibranch <code>client.mk</code> and the Camino version file:

cvs tag -b CAMINO_1_6_B3_MINIBRANCH client.mk camino/config/version.txt
cvs update -r CAMINO_1_6_B3_MINIBRANCH client.mk camino/config/version.txt

== Fix your (my) mistakes ==

At this point, I realized that the <code>FIREFOX_1_5_0_10_RELEASE</code> tag didn’t include changes to two Camino files that had been made recently on the <code>MOZILLA_1_8_0_BRANCH</code> in anticipation of Camino 1.0.4. I realized this because the release notes were missing. I found the other file by querying [http://bonsai.mozilla.org/ 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 <code>cvs tag -B -F</code> to move the tag because <code>ad_blocking.css</code> had already been branched. <code>cvs tag -B -F</code> 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 <code>client.mk</code> apply to the release tag ==

Now it’s possible to make changes to the working copy. First, update <code>client.mk</code> so that it will pull from the release tag (soon to be created). The relevant section of <code>client.mk</code> should look something like [http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/client.mk&rev=CAMINO_1_0_4_RELEASE&mark=241-245#236 this]. In this case, <code>sed</code> 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 <code>client.mk</code>. 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 [https://bugzilla.mozilla.org/buglist.cgi?status_whiteboard_type=substring&status_whiteboard=camino-1.0.3 querying Bugzilla for bugs with text like <code>camino-1.0.3</code>] in the status whiteboard field, by [http://bonsai.mozilla.org/cvsquery.cgi?branch=CAMINO_1_0_3_MINIBRANCH&date=all checking Bonsai for changes I made to the last release minibranch], or by asking [[User:Sardisson|Smokey]] or [[User:Admin|Sam]]. Those guys remember everything. These two things come from bugs [https://bugzilla.mozilla.org/show_bug.cgi?id=325765 325765] and [https://bugzilla.mozilla.org/show_bug.cgi?id=325964 325964]. When landing things on the minibranch, don’t forget to update the status whiteboard fields of the relevant bugs with text like <code>[camino-1.0.4]</code>.

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

With recent branches, often the only change after the <code>client.mk</code> change is to update the Camino version file:

echo 1.6b3 > camino/config/version.txt
cvs commit -m "Numbers for Camino 1.6b3" client.mk camino/config/version.txt

== Release checklist ==

Run the release checklist in [http://lxr.mozilla.org/mozilla/source/camino/docs/ReleaseChecklist.txt <code>camino/docs/ReleaseChecklist.txt</code>] 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 ..

On recent branches, if you’ve been following this guide, by the time you run the release checklist, there shouldn’t be any actual work to do. It should be a simple verification that the source tree is ready for a release.

You also might want to update the version numbers on the parent branch (<code>MOZILLA_1_8_0_BRANCH</code> 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+, but this versioning scheme is deprecated. Under the new scheme, the version number should be updated the the next version expected to be released from the branch, with “pre” appended. In this example, the version would be updated to 1.0.5pre. 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 <code>client.mk</code> 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 <code>client.mk</code> by the <code>CAMINO_1_0_4_RELEASE</code> tag, then they’ll get what they expect. Change the tags in <code>client.mk</code> 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.) This is only recommended if the entire tree was forked to make a minibranch, otherwise, it’s pointless. If using a Gecko release branch (recommended), you probably won’t have forked the entire tree for a minibranch, so this step is safe to skip.

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 used to be crappy and top-secret, and fortunately, it’s no longer necessary now that tinderbox can use <code>$UsePrebuiltTalkback</code>. The old procedure is included here to confuse you. We used to need to tag the Talkback tree too, so that tinderbox would get the right stuff. We only had access to that from the tinderbox itself. I’m not going to tell you what we used for <code>$CVSROOT</code>, but you could have found 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 <code>$BuildTag</code> in <code>tinder-config.pl</code> to make sure it corresponds to your chosen release tag (or branch). When building from a tag (instead of a branch), pull-by-timestamp (<code>cvs checkout -D</code>) must be turned off. It’s useful when building from branches. Its behavior is controlled by the <code>$UseTimeStamp</code> 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

Other significant variables affect the name displayed on the tinderbox status page, and the names of the directories created on the FTP server:

$BuildNameExtra = 'Cm1.0.4';
$milestone = "1.0.4";

Now, edit <code>multi-tinderbox</code>’ 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 <code>Cm1.0-M1.8.0</code> and adding a <code>Cm1.0.4</code> entry. Later, when the release is built, I’ll comment out <code>Cm1.0.4</code> and turn <code>Cm1.0-M1.8.0</code> back on. <code>multi-tinderbox</code> reloads its configuration when it receives a <code>SIGHUP</code>; 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 <code>multi-config.pl</code>.

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 <code>multi-tinderbox</code> to reload when the current build finishes:

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

When the release build begins, go to the [http://tinderbox.mozilla.org/Camino/ Camino tinderbox page], click “[http://tinderbox.mozilla.org/admintree.cgi?tree=Camino 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 your (my) mistakes|“fix-it”]] section above where I fixed <code>ad_blocking.css</code>, remembering that at this point, you’ve got both a <code>_MINIBRANCH</code> and <code>_RELEASE</code> 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 “[http://ftp.mozilla.org/pub/mozilla.org/camino/nightly/ nightly]” that tinderbox uploaded. If it seems reasonable, stage it and let people know. When possible, it’s nice to let the [http://caminol10n.mozdev.org/ 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 <code>/home/ftp/pub/camino/source/camino-1.0.4.tar.bz2</code>, and that directory has an <code>MD5SUMS</code> file as well. The multilingual release will go in
<code>/home/ftp/pub/camino/releases/Camino-1.0.4-MultiLang.dmg</code>, with a copy at <code>/home/ftp/pub/camino/releases/all/Camino-1.0.4.dmg</code>.

== Create a source release ==

We provide [http://ftp.mozilla.org/pub/mozilla.org/camino/source/ source tarballs] for major releases (not alphas, betas, or release candidates). Check out a fresh tree using anonymous CVS, so that the <code>CVS/Root</code> files are correct for people bootstrapping anonymous CVS workspaces. If the <code>.tar.bz2</code> 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
rm .mozconfig.mk .mozconfig.out
cd ..
chmod -R a+rX mozilla
BZIP2=-9 tar --owner 0 --group 0 -jcf camino-1.0.4.tar.bz2 mozilla

Stage the source release as described above in [[#Stage it|Stage it]].

== Have someone else set up Talkback reports ==

Ask Sam to set up [http://talkback-public.mozilla.org/reports/camino/ Talkback reports], at least until [http://code.google.com/p/google-breakpad/ 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 <code>Contents/MacOS/components/talkback/master.ini</code> file from <code>Camino.app</code> 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.

* Wait for mirror propagation from <code>stage.mozilla.org</code> to all of the systems handling <code>releases.mozilla.org</code>, <code>ftp.mozilla.org</code>, and other mirrors.
* Have someone on the build team update bouncer. [https://bugzilla.mozilla.org/enter_bug.cgi?product=mozilla.org&component=Build%20%26%20Release File a bug in the “mozilla.org:Build & Release” component], or e-mail [mailto:build@mozilla.org build@mozilla.org]. If you forget how to accomplish this step, ask Reed. He’s always happy to remind us.
* Someone’s got to [[Releases:Website Checklist|update the website]], the web site, or both.
* Some releases include a “release notes” URL that needs to be populated with content or a redirect. The release notes URL is defined as <code>ReleaseNotesDefault</code> in [http://lxr.mozilla.org/mozilla1.8.0/source/camino/resources/application/WebsiteDefaults.strings <code>camino/resources/application/WebsiteDefaults.strings</code>] and is updated as part of the [[#Release checklist|release checklist]]. The URL used in Camino 1.0.4 is [http://www.mozilla.org/products/camino/releases/1.0.4.html], which redirects to [http://www.caminobrowser.org/releases/1.0.4.php].

Releases:Branch Tag Build Release

2008-03-25T02:52:19Z

Mento: /* Land other changes on the minibranch */

<big>How to (branch and tag and build and) release a new version of Camino</big>
 
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 [http://www.caminobrowser.org/releases/1.0.4.php Camino 1.0.4] ([http://www.mozilla.com/en-US/firefox/releases/1.5.0.10.html Gecko 1.8.0.10]). The base tag for this release was <code>FIREFOX_1_5_0_10_RELEASE</code>. This specifies the apex of the minibranch. For the 1.0.4 release, changes to that tag for Camino were made on a new <code>CAMINO_1_0_4_MINIBRANCH</code> branch, and the release tag was <code>CAMINO_1_0_4_RELEASE</code>. Camino branch and release tags follow this convention (<code>CAMINO_1_1_A2_MINIBRANCH</code>, <code>CAMINO_1_1_B_RELEASE</code>).

== 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 <code>-D</code> when checking out <code>client.mk</code>, and set <code>MOZ_CO_DATE</code> when making <code>client.mk</code>’s <code>checkout</code> 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 [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. (KaiRo has a [http://dev.seamonkey.at/?d=x&i=mozilla&m=t tool] that periodically queries tags, or you can use <code>cvs log</code> or perhaps even [http://bonsai.mozilla.org/cvsgraph.cgi?file=/mozilla/camino/config/version.txt bonsai] (or [http://bonsai.mozilla.org/cvsgraph.cgi?file=/mozilla/camino/resources/application/all-camino.js this link] for older branches) to find relevant Gecko tags.)

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). Note that we’ve been asked not to check in to this branch, even in <code>mozilla/camino</code>, so our own minibranch (below) is still needed.

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

In some cases, it’s not proper to base a Camino release off of an entire Gecko tree. For example, Camino 1.5.1 is based on <code>FIREFOX_2_0_0_6_RELEASE</code> in all directories except for <code>mozilla/camino</code>, which is based on then-current code from <code>CAMINO_1_5_BRANCH</code>. To switch the base in <code>mozilla/camino</code>, after the initial checkout above, do:

cvs update -r CAMINO_1_5_BRANCH -Pd camino

== Fork a minibranch ==

This can be done either by branching the entire checked-out tree, or branching individual files as needed. <code>client.mk</code> always needs 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 <code>client.mk</code> if that’s all that’s changing. After branching, use <code>cvs update</code> 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 (<code>mozilla</code>).

cvs tag -b CAMINO_1_0_4_MINIBRANCH
cvs update -r CAMINO_1_0_4_MINIBRANCH

This usage only branches the individual files which will be modified from the base tag(s) for inclusion in the release tag:

cvs tag -b CAMINO_1_5_1_MINIBRANCH \
client.mk \
camino/Info-Camino.plist \
camino/Info-CaminoStatic.plist \
camino/resources/application/all-camino.js \
camino/resources/localized/English.lproj/InfoPlist.strings
cvs update -r CAMINO_1_5_1_MINIBRANCH \
client.mk \
camino/Info-Camino.plist \
camino/Info-CaminoStatic.plist \
camino/resources/application/all-camino.js \
camino/resources/localized/English.lproj/InfoPlist.strings

With recent branches, it is often only necessary to minibranch <code>client.mk</code> and the Camino version file:

cvs tag -b CAMINO_1_6_B3_MINIBRANCH client.mk camino/config/version.txt
cvs update -r CAMINO_1_6_B3_MINIBRANCH client.mk camino/config/version.txt

== Fix your (my) mistakes ==

At this point, I realized that the <code>FIREFOX_1_5_0_10_RELEASE</code> tag didn’t include changes to two Camino files that had been made recently on the <code>MOZILLA_1_8_0_BRANCH</code> in anticipation of Camino 1.0.4. I realized this because the release notes were missing. I found the other file by querying [http://bonsai.mozilla.org/ 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 <code>cvs tag -B -F</code> to move the tag because <code>ad_blocking.css</code> had already been branched. <code>cvs tag -B -F</code> 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 <code>client.mk</code> apply to the release tag ==

Now it’s possible to make changes to the working copy. First, update <code>client.mk</code> so that it will pull from the release tag (soon to be created). The relevant section of <code>client.mk</code> should look something like [http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/client.mk&rev=CAMINO_1_0_4_RELEASE&mark=241-245#236 this]. In this case, <code>sed</code> 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 <code>client.mk</code>. 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 [https://bugzilla.mozilla.org/buglist.cgi?status_whiteboard_type=substring&status_whiteboard=camino-1.0.3 querying Bugzilla for bugs with text like <code>camino-1.0.3</code>] in the status whiteboard field, by [http://bonsai.mozilla.org/cvsquery.cgi?branch=CAMINO_1_0_3_MINIBRANCH&date=all checking Bonsai for changes I made to the last release minibranch], or by asking [[User:Sardisson|Smokey]] or [[User:Admin|Sam]]. Those guys remember everything. These two things come from bugs [https://bugzilla.mozilla.org/show_bug.cgi?id=325765 325765] and [https://bugzilla.mozilla.org/show_bug.cgi?id=325964 325964]. When landing things on the minibranch, don’t forget to update the status whiteboard fields of the relevant bugs with text like <code>[camino-1.0.4]</code>.

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

With recent branches, often the only change after the <code>client.mk</code> change is to update the Camino version file:

echo 1.6b3 > camino/config/version.txt
cvs commit -m "Numbers for Camino 1.6b3" client.mk camino/config/version.txt

== Release checklist ==

Run the release checklist in [http://lxr.mozilla.org/mozilla/source/camino/docs/ReleaseChecklist.txt <code>camino/docs/ReleaseChecklist.txt</code>] 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 (<code>MOZILLA_1_8_0_BRANCH</code> 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+, but this versioning scheme is deprecated. Under the new scheme, the version number should be updated the the next version expected to be released from the branch, with “pre” appended. In this example, the version would be updated to 1.0.5pre. 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 <code>client.mk</code> 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 <code>client.mk</code> by the <code>CAMINO_1_0_4_RELEASE</code> tag, then they’ll get what they expect. Change the tags in <code>client.mk</code> 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.) This is only recommended if the entire tree was forked to make a minibranch, otherwise, it’s pointless. If using a Gecko release branch (recommended), you probably won’t have forked the entire tree for a minibranch, so this step is safe to skip.

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 used to be crappy and top-secret, and fortunately, it’s no longer necessary now that tinderbox can use <code>$UsePrebuiltTalkback</code>. The old procedure is included here to confuse you. We used to need to tag the Talkback tree too, so that tinderbox would get the right stuff. We only had access to that from the tinderbox itself. I’m not going to tell you what we used for <code>$CVSROOT</code>, but you could have found 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 <code>$BuildTag</code> in <code>tinder-config.pl</code> to make sure it corresponds to your chosen release tag (or branch). When building from a tag (instead of a branch), pull-by-timestamp (<code>cvs checkout -D</code>) must be turned off. It’s useful when building from branches. Its behavior is controlled by the <code>$UseTimeStamp</code> 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

Other significant variables affect the name displayed on the tinderbox status page, and the names of the directories created on the FTP server:

$BuildNameExtra = 'Cm1.0.4';
$milestone = "1.0.4";

Now, edit <code>multi-tinderbox</code>’ 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 <code>Cm1.0-M1.8.0</code> and adding a <code>Cm1.0.4</code> entry. Later, when the release is built, I’ll comment out <code>Cm1.0.4</code> and turn <code>Cm1.0-M1.8.0</code> back on. <code>multi-tinderbox</code> reloads its configuration when it receives a <code>SIGHUP</code>; 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 <code>multi-config.pl</code>.

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 <code>multi-tinderbox</code> to reload when the current build finishes:

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

When the release build begins, go to the [http://tinderbox.mozilla.org/Camino/ Camino tinderbox page], click “[http://tinderbox.mozilla.org/admintree.cgi?tree=Camino 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 your (my) mistakes|“fix-it”]] section above where I fixed <code>ad_blocking.css</code>, remembering that at this point, you’ve got both a <code>_MINIBRANCH</code> and <code>_RELEASE</code> 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 “[http://ftp.mozilla.org/pub/mozilla.org/camino/nightly/ nightly]” that tinderbox uploaded. If it seems reasonable, stage it and let people know. When possible, it’s nice to let the [http://caminol10n.mozdev.org/ 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 <code>/home/ftp/pub/camino/source/camino-1.0.4.tar.bz2</code>, and that directory has an <code>MD5SUMS</code> file as well. The multilingual release will go in
<code>/home/ftp/pub/camino/releases/Camino-1.0.4-MultiLang.dmg</code>, with a copy at <code>/home/ftp/pub/camino/releases/all/Camino-1.0.4.dmg</code>.

== Create a source release ==

We provide [http://ftp.mozilla.org/pub/mozilla.org/camino/source/ source tarballs] for major releases (not alphas, betas, or release candidates). Check out a fresh tree using anonymous CVS, so that the <code>CVS/Root</code> files are correct for people bootstrapping anonymous CVS workspaces. If the <code>.tar.bz2</code> 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
rm .mozconfig.mk .mozconfig.out
cd ..
chmod -R a+rX mozilla
BZIP2=-9 tar --owner 0 --group 0 -jcf camino-1.0.4.tar.bz2 mozilla

Stage the source release as described above in [[#Stage it|Stage it]].

== Have someone else set up Talkback reports ==

Ask Sam to set up [http://talkback-public.mozilla.org/reports/camino/ Talkback reports], at least until [http://code.google.com/p/google-breakpad/ 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 <code>Contents/MacOS/components/talkback/master.ini</code> file from <code>Camino.app</code> 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.

* Wait for mirror propagation from <code>stage.mozilla.org</code> to all of the systems handling <code>releases.mozilla.org</code>, <code>ftp.mozilla.org</code>, and other mirrors.
* Have someone on the build team update bouncer. [https://bugzilla.mozilla.org/enter_bug.cgi?product=mozilla.org&component=Build%20%26%20Release File a bug in the “mozilla.org:Build & Release” component], or e-mail [mailto:build@mozilla.org build@mozilla.org]. If you forget how to accomplish this step, ask Reed. He’s always happy to remind us.
* Someone’s got to [[Releases:Website Checklist|update the website]], the web site, or both.
* Some releases include a “release notes” URL that needs to be populated with content or a redirect. The release notes URL is defined as <code>ReleaseNotesDefault</code> in [http://lxr.mozilla.org/mozilla1.8.0/source/camino/resources/application/WebsiteDefaults.strings <code>camino/resources/application/WebsiteDefaults.strings</code>] and is updated as part of the [[#Release checklist|release checklist]]. The URL used in Camino 1.0.4 is [http://www.mozilla.org/products/camino/releases/1.0.4.html], which redirects to [http://www.caminobrowser.org/releases/1.0.4.php].

Releases:Branch Tag Build Release

2008-03-25T02:51:19Z

Mento: /* Land other changes on the minibranch */ Reflect current practices

<big>How to (branch and tag and build and) release a new version of Camino</big>
 
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 [http://www.caminobrowser.org/releases/1.0.4.php Camino 1.0.4] ([http://www.mozilla.com/en-US/firefox/releases/1.5.0.10.html Gecko 1.8.0.10]). The base tag for this release was <code>FIREFOX_1_5_0_10_RELEASE</code>. This specifies the apex of the minibranch. For the 1.0.4 release, changes to that tag for Camino were made on a new <code>CAMINO_1_0_4_MINIBRANCH</code> branch, and the release tag was <code>CAMINO_1_0_4_RELEASE</code>. Camino branch and release tags follow this convention (<code>CAMINO_1_1_A2_MINIBRANCH</code>, <code>CAMINO_1_1_B_RELEASE</code>).

== 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 <code>-D</code> when checking out <code>client.mk</code>, and set <code>MOZ_CO_DATE</code> when making <code>client.mk</code>’s <code>checkout</code> 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 [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. (KaiRo has a [http://dev.seamonkey.at/?d=x&i=mozilla&m=t tool] that periodically queries tags, or you can use <code>cvs log</code> or perhaps even [http://bonsai.mozilla.org/cvsgraph.cgi?file=/mozilla/camino/config/version.txt bonsai] (or [http://bonsai.mozilla.org/cvsgraph.cgi?file=/mozilla/camino/resources/application/all-camino.js this link] for older branches) to find relevant Gecko tags.)

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). Note that we’ve been asked not to check in to this branch, even in <code>mozilla/camino</code>, so our own minibranch (below) is still needed.

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

In some cases, it’s not proper to base a Camino release off of an entire Gecko tree. For example, Camino 1.5.1 is based on <code>FIREFOX_2_0_0_6_RELEASE</code> in all directories except for <code>mozilla/camino</code>, which is based on then-current code from <code>CAMINO_1_5_BRANCH</code>. To switch the base in <code>mozilla/camino</code>, after the initial checkout above, do:

cvs update -r CAMINO_1_5_BRANCH -Pd camino

== Fork a minibranch ==

This can be done either by branching the entire checked-out tree, or branching individual files as needed. <code>client.mk</code> always needs 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 <code>client.mk</code> if that’s all that’s changing. After branching, use <code>cvs update</code> 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 (<code>mozilla</code>).

cvs tag -b CAMINO_1_0_4_MINIBRANCH
cvs update -r CAMINO_1_0_4_MINIBRANCH

This usage only branches the individual files which will be modified from the base tag(s) for inclusion in the release tag:

cvs tag -b CAMINO_1_5_1_MINIBRANCH \
client.mk \
camino/Info-Camino.plist \
camino/Info-CaminoStatic.plist \
camino/resources/application/all-camino.js \
camino/resources/localized/English.lproj/InfoPlist.strings
cvs update -r CAMINO_1_5_1_MINIBRANCH \
client.mk \
camino/Info-Camino.plist \
camino/Info-CaminoStatic.plist \
camino/resources/application/all-camino.js \
camino/resources/localized/English.lproj/InfoPlist.strings

With recent branches, it is often only necessary to minibranch <code>client.mk</code> and the Camino version file:

cvs tag -b CAMINO_1_6_B3_MINIBRANCH client.mk camino/config/version.txt
cvs update -r CAMINO_1_6_B3_MINIBRANCH client.mk camino/config/version.txt

== Fix your (my) mistakes ==

At this point, I realized that the <code>FIREFOX_1_5_0_10_RELEASE</code> tag didn’t include changes to two Camino files that had been made recently on the <code>MOZILLA_1_8_0_BRANCH</code> in anticipation of Camino 1.0.4. I realized this because the release notes were missing. I found the other file by querying [http://bonsai.mozilla.org/ 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 <code>cvs tag -B -F</code> to move the tag because <code>ad_blocking.css</code> had already been branched. <code>cvs tag -B -F</code> 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 <code>client.mk</code> apply to the release tag ==

Now it’s possible to make changes to the working copy. First, update <code>client.mk</code> so that it will pull from the release tag (soon to be created). The relevant section of <code>client.mk</code> should look something like [http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/client.mk&rev=CAMINO_1_0_4_RELEASE&mark=241-245#236 this]. In this case, <code>sed</code> 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 <code>client.mk</code>. 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 [https://bugzilla.mozilla.org/buglist.cgi?status_whiteboard_type=substring&status_whiteboard=camino-1.0.3 querying Bugzilla for bugs with text like <code>camino-1.0.3</code>] in the status whiteboard field, by [http://bonsai.mozilla.org/cvsquery.cgi?branch=CAMINO_1_0_3_MINIBRANCH&date=all checking Bonsai for changes I made to the last release minibranch], or by asking [[User:Sardisson|Smokey]] or [[User:Admin|Sam]]. Those guys remember everything. These two things come from bugs [https://bugzilla.mozilla.org/show_bug.cgi?id=325765 325765] and [https://bugzilla.mozilla.org/show_bug.cgi?id=325964 325964]. When landing things on the minibranch, don’t forget to update the status whiteboard fields of the relevant bugs with text like <code>[camino-1.0.4]</code>.

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

With recent branches, often the only change after the <code>client.mk</code> change is to update the Camino version file:

echo 1.6b3 > camino/config/version.txt

== Release checklist ==

Run the release checklist in [http://lxr.mozilla.org/mozilla/source/camino/docs/ReleaseChecklist.txt <code>camino/docs/ReleaseChecklist.txt</code>] 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 (<code>MOZILLA_1_8_0_BRANCH</code> 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+, but this versioning scheme is deprecated. Under the new scheme, the version number should be updated the the next version expected to be released from the branch, with “pre” appended. In this example, the version would be updated to 1.0.5pre. 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 <code>client.mk</code> 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 <code>client.mk</code> by the <code>CAMINO_1_0_4_RELEASE</code> tag, then they’ll get what they expect. Change the tags in <code>client.mk</code> 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.) This is only recommended if the entire tree was forked to make a minibranch, otherwise, it’s pointless. If using a Gecko release branch (recommended), you probably won’t have forked the entire tree for a minibranch, so this step is safe to skip.

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 used to be crappy and top-secret, and fortunately, it’s no longer necessary now that tinderbox can use <code>$UsePrebuiltTalkback</code>. The old procedure is included here to confuse you. We used to need to tag the Talkback tree too, so that tinderbox would get the right stuff. We only had access to that from the tinderbox itself. I’m not going to tell you what we used for <code>$CVSROOT</code>, but you could have found 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 <code>$BuildTag</code> in <code>tinder-config.pl</code> to make sure it corresponds to your chosen release tag (or branch). When building from a tag (instead of a branch), pull-by-timestamp (<code>cvs checkout -D</code>) must be turned off. It’s useful when building from branches. Its behavior is controlled by the <code>$UseTimeStamp</code> 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

Other significant variables affect the name displayed on the tinderbox status page, and the names of the directories created on the FTP server:

$BuildNameExtra = 'Cm1.0.4';
$milestone = "1.0.4";

Now, edit <code>multi-tinderbox</code>’ 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 <code>Cm1.0-M1.8.0</code> and adding a <code>Cm1.0.4</code> entry. Later, when the release is built, I’ll comment out <code>Cm1.0.4</code> and turn <code>Cm1.0-M1.8.0</code> back on. <code>multi-tinderbox</code> reloads its configuration when it receives a <code>SIGHUP</code>; 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 <code>multi-config.pl</code>.

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 <code>multi-tinderbox</code> to reload when the current build finishes:

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

When the release build begins, go to the [http://tinderbox.mozilla.org/Camino/ Camino tinderbox page], click “[http://tinderbox.mozilla.org/admintree.cgi?tree=Camino 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 your (my) mistakes|“fix-it”]] section above where I fixed <code>ad_blocking.css</code>, remembering that at this point, you’ve got both a <code>_MINIBRANCH</code> and <code>_RELEASE</code> 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 “[http://ftp.mozilla.org/pub/mozilla.org/camino/nightly/ nightly]” that tinderbox uploaded. If it seems reasonable, stage it and let people know. When possible, it’s nice to let the [http://caminol10n.mozdev.org/ 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 <code>/home/ftp/pub/camino/source/camino-1.0.4.tar.bz2</code>, and that directory has an <code>MD5SUMS</code> file as well. The multilingual release will go in
<code>/home/ftp/pub/camino/releases/Camino-1.0.4-MultiLang.dmg</code>, with a copy at <code>/home/ftp/pub/camino/releases/all/Camino-1.0.4.dmg</code>.

== Create a source release ==

We provide [http://ftp.mozilla.org/pub/mozilla.org/camino/source/ source tarballs] for major releases (not alphas, betas, or release candidates). Check out a fresh tree using anonymous CVS, so that the <code>CVS/Root</code> files are correct for people bootstrapping anonymous CVS workspaces. If the <code>.tar.bz2</code> 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
rm .mozconfig.mk .mozconfig.out
cd ..
chmod -R a+rX mozilla
BZIP2=-9 tar --owner 0 --group 0 -jcf camino-1.0.4.tar.bz2 mozilla

Stage the source release as described above in [[#Stage it|Stage it]].

== Have someone else set up Talkback reports ==

Ask Sam to set up [http://talkback-public.mozilla.org/reports/camino/ Talkback reports], at least until [http://code.google.com/p/google-breakpad/ 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 <code>Contents/MacOS/components/talkback/master.ini</code> file from <code>Camino.app</code> 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.

* Wait for mirror propagation from <code>stage.mozilla.org</code> to all of the systems handling <code>releases.mozilla.org</code>, <code>ftp.mozilla.org</code>, and other mirrors.
* Have someone on the build team update bouncer. [https://bugzilla.mozilla.org/enter_bug.cgi?product=mozilla.org&component=Build%20%26%20Release File a bug in the “mozilla.org:Build & Release” component], or e-mail [mailto:build@mozilla.org build@mozilla.org]. If you forget how to accomplish this step, ask Reed. He’s always happy to remind us.
* Someone’s got to [[Releases:Website Checklist|update the website]], the web site, or both.
* Some releases include a “release notes” URL that needs to be populated with content or a redirect. The release notes URL is defined as <code>ReleaseNotesDefault</code> in [http://lxr.mozilla.org/mozilla1.8.0/source/camino/resources/application/WebsiteDefaults.strings <code>camino/resources/application/WebsiteDefaults.strings</code>] and is updated as part of the [[#Release checklist|release checklist]]. The URL used in Camino 1.0.4 is [http://www.mozilla.org/products/camino/releases/1.0.4.html], which redirects to [http://www.caminobrowser.org/releases/1.0.4.php].

Releases:Branch Tag Build Release

2008-03-25T02:48:50Z

Mento: /* Fork a minibranch */ Indicate that recent branches need minimal minibranching action

<big>How to (branch and tag and build and) release a new version of Camino</big>
 
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 [http://www.caminobrowser.org/releases/1.0.4.php Camino 1.0.4] ([http://www.mozilla.com/en-US/firefox/releases/1.5.0.10.html Gecko 1.8.0.10]). The base tag for this release was <code>FIREFOX_1_5_0_10_RELEASE</code>. This specifies the apex of the minibranch. For the 1.0.4 release, changes to that tag for Camino were made on a new <code>CAMINO_1_0_4_MINIBRANCH</code> branch, and the release tag was <code>CAMINO_1_0_4_RELEASE</code>. Camino branch and release tags follow this convention (<code>CAMINO_1_1_A2_MINIBRANCH</code>, <code>CAMINO_1_1_B_RELEASE</code>).

== 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 <code>-D</code> when checking out <code>client.mk</code>, and set <code>MOZ_CO_DATE</code> when making <code>client.mk</code>’s <code>checkout</code> 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 [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. (KaiRo has a [http://dev.seamonkey.at/?d=x&i=mozilla&m=t tool] that periodically queries tags, or you can use <code>cvs log</code> or perhaps even [http://bonsai.mozilla.org/cvsgraph.cgi?file=/mozilla/camino/config/version.txt bonsai] (or [http://bonsai.mozilla.org/cvsgraph.cgi?file=/mozilla/camino/resources/application/all-camino.js this link] for older branches) to find relevant Gecko tags.)

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). Note that we’ve been asked not to check in to this branch, even in <code>mozilla/camino</code>, so our own minibranch (below) is still needed.

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

In some cases, it’s not proper to base a Camino release off of an entire Gecko tree. For example, Camino 1.5.1 is based on <code>FIREFOX_2_0_0_6_RELEASE</code> in all directories except for <code>mozilla/camino</code>, which is based on then-current code from <code>CAMINO_1_5_BRANCH</code>. To switch the base in <code>mozilla/camino</code>, after the initial checkout above, do:

cvs update -r CAMINO_1_5_BRANCH -Pd camino

== Fork a minibranch ==

This can be done either by branching the entire checked-out tree, or branching individual files as needed. <code>client.mk</code> always needs 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 <code>client.mk</code> if that’s all that’s changing. After branching, use <code>cvs update</code> 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 (<code>mozilla</code>).

cvs tag -b CAMINO_1_0_4_MINIBRANCH
cvs update -r CAMINO_1_0_4_MINIBRANCH

This usage only branches the individual files which will be modified from the base tag(s) for inclusion in the release tag:

cvs tag -b CAMINO_1_5_1_MINIBRANCH \
client.mk \
camino/Info-Camino.plist \
camino/Info-CaminoStatic.plist \
camino/resources/application/all-camino.js \
camino/resources/localized/English.lproj/InfoPlist.strings
cvs update -r CAMINO_1_5_1_MINIBRANCH \
client.mk \
camino/Info-Camino.plist \
camino/Info-CaminoStatic.plist \
camino/resources/application/all-camino.js \
camino/resources/localized/English.lproj/InfoPlist.strings

With recent branches, it is often only necessary to minibranch <code>client.mk</code> and the Camino version file:

cvs tag -b CAMINO_1_6_B3_MINIBRANCH client.mk camino/config/version.txt
cvs update -r CAMINO_1_6_B3_MINIBRANCH client.mk camino/config/version.txt

== Fix your (my) mistakes ==

At this point, I realized that the <code>FIREFOX_1_5_0_10_RELEASE</code> tag didn’t include changes to two Camino files that had been made recently on the <code>MOZILLA_1_8_0_BRANCH</code> in anticipation of Camino 1.0.4. I realized this because the release notes were missing. I found the other file by querying [http://bonsai.mozilla.org/ 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 <code>cvs tag -B -F</code> to move the tag because <code>ad_blocking.css</code> had already been branched. <code>cvs tag -B -F</code> 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 <code>client.mk</code> apply to the release tag ==

Now it’s possible to make changes to the working copy. First, update <code>client.mk</code> so that it will pull from the release tag (soon to be created). The relevant section of <code>client.mk</code> should look something like [http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/client.mk&rev=CAMINO_1_0_4_RELEASE&mark=241-245#236 this]. In this case, <code>sed</code> 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 <code>client.mk</code>. 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 [https://bugzilla.mozilla.org/buglist.cgi?status_whiteboard_type=substring&status_whiteboard=camino-1.0.3 querying Bugzilla for bugs with text like <code>camino-1.0.3</code>] in the status whiteboard field, by [http://bonsai.mozilla.org/cvsquery.cgi?branch=CAMINO_1_0_3_MINIBRANCH&date=all checking Bonsai for changes I made to the last release minibranch], or by asking [[User:Sardisson|Smokey]] or [[User:Admin|Sam]]. Those guys remember everything. These two things come from bugs [https://bugzilla.mozilla.org/show_bug.cgi?id=325765 325765] and [https://bugzilla.mozilla.org/show_bug.cgi?id=325964 325964]. When landing things on the minibranch, don’t forget to update the status whiteboard fields of the relevant bugs with text like <code>[camino-1.0.4]</code>.

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 [http://lxr.mozilla.org/mozilla/source/camino/docs/ReleaseChecklist.txt <code>camino/docs/ReleaseChecklist.txt</code>] 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 (<code>MOZILLA_1_8_0_BRANCH</code> 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+, but this versioning scheme is deprecated. Under the new scheme, the version number should be updated the the next version expected to be released from the branch, with “pre” appended. In this example, the version would be updated to 1.0.5pre. 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 <code>client.mk</code> 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 <code>client.mk</code> by the <code>CAMINO_1_0_4_RELEASE</code> tag, then they’ll get what they expect. Change the tags in <code>client.mk</code> 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.) This is only recommended if the entire tree was forked to make a minibranch, otherwise, it’s pointless. If using a Gecko release branch (recommended), you probably won’t have forked the entire tree for a minibranch, so this step is safe to skip.

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 used to be crappy and top-secret, and fortunately, it’s no longer necessary now that tinderbox can use <code>$UsePrebuiltTalkback</code>. The old procedure is included here to confuse you. We used to need to tag the Talkback tree too, so that tinderbox would get the right stuff. We only had access to that from the tinderbox itself. I’m not going to tell you what we used for <code>$CVSROOT</code>, but you could have found 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 <code>$BuildTag</code> in <code>tinder-config.pl</code> to make sure it corresponds to your chosen release tag (or branch). When building from a tag (instead of a branch), pull-by-timestamp (<code>cvs checkout -D</code>) must be turned off. It’s useful when building from branches. Its behavior is controlled by the <code>$UseTimeStamp</code> 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

Other significant variables affect the name displayed on the tinderbox status page, and the names of the directories created on the FTP server:

$BuildNameExtra = 'Cm1.0.4';
$milestone = "1.0.4";

Now, edit <code>multi-tinderbox</code>’ 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 <code>Cm1.0-M1.8.0</code> and adding a <code>Cm1.0.4</code> entry. Later, when the release is built, I’ll comment out <code>Cm1.0.4</code> and turn <code>Cm1.0-M1.8.0</code> back on. <code>multi-tinderbox</code> reloads its configuration when it receives a <code>SIGHUP</code>; 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 <code>multi-config.pl</code>.

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 <code>multi-tinderbox</code> to reload when the current build finishes:

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

When the release build begins, go to the [http://tinderbox.mozilla.org/Camino/ Camino tinderbox page], click “[http://tinderbox.mozilla.org/admintree.cgi?tree=Camino 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 your (my) mistakes|“fix-it”]] section above where I fixed <code>ad_blocking.css</code>, remembering that at this point, you’ve got both a <code>_MINIBRANCH</code> and <code>_RELEASE</code> 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 “[http://ftp.mozilla.org/pub/mozilla.org/camino/nightly/ nightly]” that tinderbox uploaded. If it seems reasonable, stage it and let people know. When possible, it’s nice to let the [http://caminol10n.mozdev.org/ 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 <code>/home/ftp/pub/camino/source/camino-1.0.4.tar.bz2</code>, and that directory has an <code>MD5SUMS</code> file as well. The multilingual release will go in
<code>/home/ftp/pub/camino/releases/Camino-1.0.4-MultiLang.dmg</code>, with a copy at <code>/home/ftp/pub/camino/releases/all/Camino-1.0.4.dmg</code>.

== Create a source release ==

We provide [http://ftp.mozilla.org/pub/mozilla.org/camino/source/ source tarballs] for major releases (not alphas, betas, or release candidates). Check out a fresh tree using anonymous CVS, so that the <code>CVS/Root</code> files are correct for people bootstrapping anonymous CVS workspaces. If the <code>.tar.bz2</code> 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
rm .mozconfig.mk .mozconfig.out
cd ..
chmod -R a+rX mozilla
BZIP2=-9 tar --owner 0 --group 0 -jcf camino-1.0.4.tar.bz2 mozilla

Stage the source release as described above in [[#Stage it|Stage it]].

== Have someone else set up Talkback reports ==

Ask Sam to set up [http://talkback-public.mozilla.org/reports/camino/ Talkback reports], at least until [http://code.google.com/p/google-breakpad/ 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 <code>Contents/MacOS/components/talkback/master.ini</code> file from <code>Camino.app</code> 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.

* Wait for mirror propagation from <code>stage.mozilla.org</code> to all of the systems handling <code>releases.mozilla.org</code>, <code>ftp.mozilla.org</code>, and other mirrors.
* Have someone on the build team update bouncer. [https://bugzilla.mozilla.org/enter_bug.cgi?product=mozilla.org&component=Build%20%26%20Release File a bug in the “mozilla.org:Build & Release” component], or e-mail [mailto:build@mozilla.org build@mozilla.org]. If you forget how to accomplish this step, ask Reed. He’s always happy to remind us.
* Someone’s got to [[Releases:Website Checklist|update the website]], the web site, or both.
* Some releases include a “release notes” URL that needs to be populated with content or a redirect. The release notes URL is defined as <code>ReleaseNotesDefault</code> in [http://lxr.mozilla.org/mozilla1.8.0/source/camino/resources/application/WebsiteDefaults.strings <code>camino/resources/application/WebsiteDefaults.strings</code>] and is updated as part of the [[#Release checklist|release checklist]]. The URL used in Camino 1.0.4 is [http://www.mozilla.org/products/camino/releases/1.0.4.html], which redirects to [http://www.caminobrowser.org/releases/1.0.4.php].

Releases:Branch Tag Build Release

2008-03-25T02:27:57Z

Mento: /* Fork a minibranch */

<big>How to (branch and tag and build and) release a new version of Camino</big>
 
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 [http://www.caminobrowser.org/releases/1.0.4.php Camino 1.0.4] ([http://www.mozilla.com/en-US/firefox/releases/1.5.0.10.html Gecko 1.8.0.10]). The base tag for this release was <code>FIREFOX_1_5_0_10_RELEASE</code>. This specifies the apex of the minibranch. For the 1.0.4 release, changes to that tag for Camino were made on a new <code>CAMINO_1_0_4_MINIBRANCH</code> branch, and the release tag was <code>CAMINO_1_0_4_RELEASE</code>. Camino branch and release tags follow this convention (<code>CAMINO_1_1_A2_MINIBRANCH</code>, <code>CAMINO_1_1_B_RELEASE</code>).

== 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 <code>-D</code> when checking out <code>client.mk</code>, and set <code>MOZ_CO_DATE</code> when making <code>client.mk</code>’s <code>checkout</code> 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 [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. (KaiRo has a [http://dev.seamonkey.at/?d=x&i=mozilla&m=t tool] that periodically queries tags, or you can use <code>cvs log</code> or perhaps even [http://bonsai.mozilla.org/cvsgraph.cgi?file=/mozilla/camino/config/version.txt bonsai] (or [http://bonsai.mozilla.org/cvsgraph.cgi?file=/mozilla/camino/resources/application/all-camino.js this link] for older branches) to find relevant Gecko tags.)

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). Note that we’ve been asked not to check in to this branch, even in <code>mozilla/camino</code>, so our own minibranch (below) is still needed.

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

In some cases, it’s not proper to base a Camino release off of an entire Gecko tree. For example, Camino 1.5.1 is based on <code>FIREFOX_2_0_0_6_RELEASE</code> in all directories except for <code>mozilla/camino</code>, which is based on then-current code from <code>CAMINO_1_5_BRANCH</code>. To switch the base in <code>mozilla/camino</code>, after the initial checkout above, do:

cvs update -r CAMINO_1_5_BRANCH -Pd camino

== Fork a minibranch ==

This can be done either by branching the entire checked-out tree, or branching individual files as needed. <code>client.mk</code> always needs 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 <code>client.mk</code> if that’s all that’s changing. After branching, use <code>cvs update</code> 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 (<code>mozilla</code>).

cvs tag -b CAMINO_1_0_4_MINIBRANCH
cvs update -r CAMINO_1_0_4_MINIBRANCH

This usage only branches the individual files which will be modified from the base tag(s) for inclusion in the release tag:

cvs tag -b CAMINO_1_5_1_MINIBRANCH \
client.mk \
camino/Info-Camino.plist \
camino/Info-CaminoStatic.plist \
camino/resources/application/all-camino.js \
camino/resources/localized/English.lproj/InfoPlist.strings
cvs update -r CAMINO_1_5_1_MINIBRANCH \
client.mk \
camino/Info-Camino.plist \
camino/Info-CaminoStatic.plist \
camino/resources/application/all-camino.js \
camino/resources/localized/English.lproj/InfoPlist.strings

== Fix your (my) mistakes ==

At this point, I realized that the <code>FIREFOX_1_5_0_10_RELEASE</code> tag didn’t include changes to two Camino files that had been made recently on the <code>MOZILLA_1_8_0_BRANCH</code> in anticipation of Camino 1.0.4. I realized this because the release notes were missing. I found the other file by querying [http://bonsai.mozilla.org/ 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 <code>cvs tag -B -F</code> to move the tag because <code>ad_blocking.css</code> had already been branched. <code>cvs tag -B -F</code> 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 <code>client.mk</code> apply to the release tag ==

Now it’s possible to make changes to the working copy. First, update <code>client.mk</code> so that it will pull from the release tag (soon to be created). The relevant section of <code>client.mk</code> should look something like [http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/client.mk&rev=CAMINO_1_0_4_RELEASE&mark=241-245#236 this]. In this case, <code>sed</code> 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 <code>client.mk</code>. 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 [https://bugzilla.mozilla.org/buglist.cgi?status_whiteboard_type=substring&status_whiteboard=camino-1.0.3 querying Bugzilla for bugs with text like <code>camino-1.0.3</code>] in the status whiteboard field, by [http://bonsai.mozilla.org/cvsquery.cgi?branch=CAMINO_1_0_3_MINIBRANCH&date=all checking Bonsai for changes I made to the last release minibranch], or by asking [[User:Sardisson|Smokey]] or [[User:Admin|Sam]]. Those guys remember everything. These two things come from bugs [https://bugzilla.mozilla.org/show_bug.cgi?id=325765 325765] and [https://bugzilla.mozilla.org/show_bug.cgi?id=325964 325964]. When landing things on the minibranch, don’t forget to update the status whiteboard fields of the relevant bugs with text like <code>[camino-1.0.4]</code>.

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 [http://lxr.mozilla.org/mozilla/source/camino/docs/ReleaseChecklist.txt <code>camino/docs/ReleaseChecklist.txt</code>] 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 (<code>MOZILLA_1_8_0_BRANCH</code> 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+, but this versioning scheme is deprecated. Under the new scheme, the version number should be updated the the next version expected to be released from the branch, with “pre” appended. In this example, the version would be updated to 1.0.5pre. 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 <code>client.mk</code> 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 <code>client.mk</code> by the <code>CAMINO_1_0_4_RELEASE</code> tag, then they’ll get what they expect. Change the tags in <code>client.mk</code> 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.) This is only recommended if the entire tree was forked to make a minibranch, otherwise, it’s pointless. If using a Gecko release branch (recommended), you probably won’t have forked the entire tree for a minibranch, so this step is safe to skip.

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 used to be crappy and top-secret, and fortunately, it’s no longer necessary now that tinderbox can use <code>$UsePrebuiltTalkback</code>. The old procedure is included here to confuse you. We used to need to tag the Talkback tree too, so that tinderbox would get the right stuff. We only had access to that from the tinderbox itself. I’m not going to tell you what we used for <code>$CVSROOT</code>, but you could have found 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 <code>$BuildTag</code> in <code>tinder-config.pl</code> to make sure it corresponds to your chosen release tag (or branch). When building from a tag (instead of a branch), pull-by-timestamp (<code>cvs checkout -D</code>) must be turned off. It’s useful when building from branches. Its behavior is controlled by the <code>$UseTimeStamp</code> 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

Other significant variables affect the name displayed on the tinderbox status page, and the names of the directories created on the FTP server:

$BuildNameExtra = 'Cm1.0.4';
$milestone = "1.0.4";

Now, edit <code>multi-tinderbox</code>’ 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 <code>Cm1.0-M1.8.0</code> and adding a <code>Cm1.0.4</code> entry. Later, when the release is built, I’ll comment out <code>Cm1.0.4</code> and turn <code>Cm1.0-M1.8.0</code> back on. <code>multi-tinderbox</code> reloads its configuration when it receives a <code>SIGHUP</code>; 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 <code>multi-config.pl</code>.

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 <code>multi-tinderbox</code> to reload when the current build finishes:

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

When the release build begins, go to the [http://tinderbox.mozilla.org/Camino/ Camino tinderbox page], click “[http://tinderbox.mozilla.org/admintree.cgi?tree=Camino 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 your (my) mistakes|“fix-it”]] section above where I fixed <code>ad_blocking.css</code>, remembering that at this point, you’ve got both a <code>_MINIBRANCH</code> and <code>_RELEASE</code> 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 “[http://ftp.mozilla.org/pub/mozilla.org/camino/nightly/ nightly]” that tinderbox uploaded. If it seems reasonable, stage it and let people know. When possible, it’s nice to let the [http://caminol10n.mozdev.org/ 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 <code>/home/ftp/pub/camino/source/camino-1.0.4.tar.bz2</code>, and that directory has an <code>MD5SUMS</code> file as well. The multilingual release will go in
<code>/home/ftp/pub/camino/releases/Camino-1.0.4-MultiLang.dmg</code>, with a copy at <code>/home/ftp/pub/camino/releases/all/Camino-1.0.4.dmg</code>.

== Create a source release ==

We provide [http://ftp.mozilla.org/pub/mozilla.org/camino/source/ source tarballs] for major releases (not alphas, betas, or release candidates). Check out a fresh tree using anonymous CVS, so that the <code>CVS/Root</code> files are correct for people bootstrapping anonymous CVS workspaces. If the <code>.tar.bz2</code> 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
rm .mozconfig.mk .mozconfig.out
cd ..
chmod -R a+rX mozilla
BZIP2=-9 tar --owner 0 --group 0 -jcf camino-1.0.4.tar.bz2 mozilla

Stage the source release as described above in [[#Stage it|Stage it]].

== Have someone else set up Talkback reports ==

Ask Sam to set up [http://talkback-public.mozilla.org/reports/camino/ Talkback reports], at least until [http://code.google.com/p/google-breakpad/ 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 <code>Contents/MacOS/components/talkback/master.ini</code> file from <code>Camino.app</code> 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.

* Wait for mirror propagation from <code>stage.mozilla.org</code> to all of the systems handling <code>releases.mozilla.org</code>, <code>ftp.mozilla.org</code>, and other mirrors.
* Have someone on the build team update bouncer. [https://bugzilla.mozilla.org/enter_bug.cgi?product=mozilla.org&component=Build%20%26%20Release File a bug in the “mozilla.org:Build & Release” component], or e-mail [mailto:build@mozilla.org build@mozilla.org]. If you forget how to accomplish this step, ask Reed. He’s always happy to remind us.
* Someone’s got to [[Releases:Website Checklist|update the website]], the web site, or both.
* Some releases include a “release notes” URL that needs to be populated with content or a redirect. The release notes URL is defined as <code>ReleaseNotesDefault</code> in [http://lxr.mozilla.org/mozilla1.8.0/source/camino/resources/application/WebsiteDefaults.strings <code>camino/resources/application/WebsiteDefaults.strings</code>] and is updated as part of the [[#Release checklist|release checklist]]. The URL used in Camino 1.0.4 is [http://www.mozilla.org/products/camino/releases/1.0.4.html], which redirects to [http://www.caminobrowser.org/releases/1.0.4.php].

Releases:Branch Tag Build Release

2007-11-28T21:13:25Z

Mento: /* Create a source release */

<big>How to (branch and tag and build and) release a new version of Camino</big>
 
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 [http://www.caminobrowser.org/releases/1.0.4.php Camino 1.0.4] ([http://www.mozilla.com/en-US/firefox/releases/1.5.0.10.html Gecko 1.8.0.10]). The base tag for this release was <code>FIREFOX_1_5_0_10_RELEASE</code>. This specifies the apex of the minibranch. For the 1.0.4 release, changes to that tag for Camino were made on a new <code>CAMINO_1_0_4_MINIBRANCH</code> branch, and the release tag was <code>CAMINO_1_0_4_RELEASE</code>. Camino branch and release tags follow this convention (<code>CAMINO_1_1_A2_MINIBRANCH</code>, <code>CAMINO_1_1_B_RELEASE</code>).

== 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 <code>-D</code> when checking out <code>client.mk</code>, and set <code>MOZ_CO_DATE</code> when making <code>client.mk</code>’s <code>checkout</code> 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 [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. (KaiRo has a [http://dev.seamonkey.at/?d=x&i=mozilla&m=t tool] that periodically queries tags, or you can use <code>cvs log</code> or perhaps even [http://bonsai.mozilla.org/cvsgraph.cgi?file=/mozilla/camino/config/version.txt bonsai] (or [http://bonsai.mozilla.org/cvsgraph.cgi?file=/mozilla/camino/resources/application/all-camino.js this link] for older branches) to find relevant Gecko tags.)

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). Note that we’ve been asked not to check in to this branch, even in <code>mozilla/camino</code>, so our own minibranch (below) is still needed.

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

In some cases, it’s not proper to base a Camino release off of an entire Gecko tree. For example, Camino 1.5.1 is based on <code>FIREFOX_2_0_0_6_RELEASE</code> in all directories except for <code>mozilla/camino</code>, which is based on then-current code from <code>CAMINO_1_5_BRANCH</code>. To switch the base in <code>mozilla/camino</code>, after the initial checkout above, do:

cvs update -r CAMINO_1_5_BRANCH -Pd camino

== Fork a minibranch ==

This can be done either by branching the entire checked-out tree, or branching individual files as needed. <code>client.mk</code> 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 <code>client.mk</code> if that’s all that’s changing. After branching, use <code>cvs update</code> 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 (<code>mozilla</code>).

cvs tag -b CAMINO_1_0_4_MINIBRANCH
cvs update -r CAMINO_1_0_4_MINIBRANCH

This usage only branches the individual files which will be modified from the base tag(s) for inclusion in the release tag:

cvs tag -b CAMINO_1_5_1_MINIBRANCH \
client.mk \
camino/Info-Camino.plist \
camino/Info-CaminoStatic.plist \
camino/resources/application/all-camino.js \
camino/resources/localized/English.lproj/InfoPlist.strings
cvs update -r CAMINO_1_5_1_MINIBRANCH \
client.mk \
camino/Info-Camino.plist \
camino/Info-CaminoStatic.plist \
camino/resources/application/all-camino.js \
camino/resources/localized/English.lproj/InfoPlist.strings

== Fix your (my) mistakes ==

At this point, I realized that the <code>FIREFOX_1_5_0_10_RELEASE</code> tag didn’t include changes to two Camino files that had been made recently on the <code>MOZILLA_1_8_0_BRANCH</code> in anticipation of Camino 1.0.4. I realized this because the release notes were missing. I found the other file by querying [http://bonsai.mozilla.org/ 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 <code>cvs tag -B -F</code> to move the tag because <code>ad_blocking.css</code> had already been branched. <code>cvs tag -B -F</code> 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 <code>client.mk</code> apply to the release tag ==

Now it’s possible to make changes to the working copy. First, update <code>client.mk</code> so that it will pull from the release tag (soon to be created). The relevant section of <code>client.mk</code> should look something like [http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/client.mk&rev=CAMINO_1_0_4_RELEASE&mark=241-245#236 this]. In this case, <code>sed</code> 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 <code>client.mk</code>. 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 [https://bugzilla.mozilla.org/buglist.cgi?status_whiteboard_type=substring&status_whiteboard=camino-1.0.3 querying Bugzilla for bugs with text like <code>camino-1.0.3</code>] in the status whiteboard field, by [http://bonsai.mozilla.org/cvsquery.cgi?branch=CAMINO_1_0_3_MINIBRANCH&date=all checking Bonsai for changes I made to the last release minibranch], or by asking [[User:Sardisson|Smokey]] or [[User:Admin|Sam]]. Those guys remember everything. These two things come from bugs [https://bugzilla.mozilla.org/show_bug.cgi?id=325765 325765] and [https://bugzilla.mozilla.org/show_bug.cgi?id=325964 325964]. When landing things on the minibranch, don’t forget to update the status whiteboard fields of the relevant bugs with text like <code>[camino-1.0.4]</code>.

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 [http://lxr.mozilla.org/mozilla/source/camino/docs/ReleaseChecklist.txt <code>camino/docs/ReleaseChecklist.txt</code>] 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 (<code>MOZILLA_1_8_0_BRANCH</code> 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+, but this versioning scheme is deprecated. Under the new scheme, the version number should be updated the the next version expected to be released from the branch, with “pre” appended. In this example, the version would be updated to 1.0.5pre. 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 <code>client.mk</code> 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 <code>client.mk</code> by the <code>CAMINO_1_0_4_RELEASE</code> tag, then they’ll get what they expect. Change the tags in <code>client.mk</code> 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.) This is only recommended if the entire tree was forked to make a minibranch, otherwise, it’s pointless. If using a Gecko release branch (recommended), you probably won’t have forked the entire tree for a minibranch, so this step is safe to skip.

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 used to be crappy and top-secret, and fortunately, it’s no longer necessary now that tinderbox can use <code>$UsePrebuiltTalkback</code>. The old procedure is included here to confuse you. We used to need to tag the Talkback tree too, so that tinderbox would get the right stuff. We only had access to that from the tinderbox itself. I’m not going to tell you what we used for <code>$CVSROOT</code>, but you could have found 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 <code>$BuildTag</code> in <code>tinder-config.pl</code> to make sure it corresponds to your chosen release tag (or branch). When building from a tag (instead of a branch), pull-by-timestamp (<code>cvs checkout -D</code>) must be turned off. It’s useful when building from branches. Its behavior is controlled by the <code>$UseTimeStamp</code> 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

Other significant variables affect the name displayed on the tinderbox status page, and the names of the directories created on the FTP server:

$BuildNameExtra = 'Cm1.0.4';
$milestone = "1.0.4";

Now, edit <code>multi-tinderbox</code>’ 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 <code>Cm1.0-M1.8.0</code> and adding a <code>Cm1.0.4</code> entry. Later, when the release is built, I’ll comment out <code>Cm1.0.4</code> and turn <code>Cm1.0-M1.8.0</code> back on. <code>multi-tinderbox</code> reloads its configuration when it receives a <code>SIGHUP</code>; 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 <code>multi-config.pl</code>.

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 <code>multi-tinderbox</code> to reload when the current build finishes:

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

When the release build begins, go to the [http://tinderbox.mozilla.org/Camino/ Camino tinderbox page], click “[http://tinderbox.mozilla.org/admintree.cgi?tree=Camino 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 your (my) mistakes|“fix-it”]] section above where I fixed <code>ad_blocking.css</code>, remembering that at this point, you’ve got both a <code>_MINIBRANCH</code> and <code>_RELEASE</code> 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 “[http://ftp.mozilla.org/pub/mozilla.org/camino/nightly/ nightly]” that tinderbox uploaded. If it seems reasonable, stage it and let people know. When possible, it’s nice to let the [http://caminol10n.mozdev.org/ 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 <code>/home/ftp/pub/camino/source/camino-1.0.4.tar.bz2</code>, and that directory has an <code>MD5SUMS</code> file as well. The multilingual release will go in
<code>/home/ftp/pub/camino/releases/Camino-1.0.4-MultiLang.dmg</code>, with a copy at <code>/home/ftp/pub/camino/releases/all/Camino-1.0.4.dmg</code>.

== Create a source release ==

We provide [http://ftp.mozilla.org/pub/mozilla.org/camino/source/ source tarballs] for major releases (not alphas, betas, or release candidates). Check out a fresh tree using anonymous CVS, so that the <code>CVS/Root</code> files are correct for people bootstrapping anonymous CVS workspaces. If the <code>.tar.bz2</code> 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
rm .mozconfig.mk .mozconfig.out
cd ..
chmod -R a+rX mozilla
BZIP2=-9 tar --owner 0 --group 0 -jcf camino-1.0.4.tar.bz2 mozilla

Stage the source release as described above in [[#Stage it|Stage it]].

== Have someone else set up Talkback reports ==

Ask Jay to set up [http://talkback-public.mozilla.org/reports/camino/ Talkback reports], at least until [http://code.google.com/p/google-breakpad/ 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 <code>Contents/MacOS/components/talkback/master.ini</code> file from <code>Camino.app</code> 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.

* Wait for mirror propagation from <code>stage.mozilla.org</code> to all of the systems handling <code>releases.mozilla.org</code>, <code>ftp.mozilla.org</code>, and other mirrors.
* Have someone on the build team update bouncer. [https://bugzilla.mozilla.org/enter_bug.cgi?product=mozilla.org&component=Build%20%26%20Release File a bug in the “mozilla.org:Build & Release” component], or e-mail [mailto:build@mozilla.org build@mozilla.org]. If you forget how to accomplish this step, ask Reed. He’s always happy to remind us.
* Someone’s got to [[Releases:Website Checklist|update the website]], the web site, or both.
* Some releases include a “release notes” URL that needs to be populated with content or a redirect. The release notes URL is defined as <code>ReleaseNotesDefault</code> in [http://lxr.mozilla.org/mozilla1.8.0/source/camino/resources/application/WebsiteDefaults.strings <code>camino/resources/application/WebsiteDefaults.strings</code>] and is updated as part of the [[#Release checklist|release checklist]]. The URL used in Camino 1.0.4 is [http://www.mozilla.org/products/camino/releases/1.0.4.html], which redirects to [http://www.caminobrowser.org/releases/1.0.4.php].

Releases:Branch Tag Build Release

2007-10-10T18:42:10Z

Mento: /* Check out the source */ Point bonsai to a live file

<big>How to (branch and tag and build and) release a new version of Camino</big>
 
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 [http://www.caminobrowser.org/releases/1.0.4.php Camino 1.0.4] ([http://www.mozilla.com/en-US/firefox/releases/1.5.0.10.html Gecko 1.8.0.10]). The base tag for this release was <code>FIREFOX_1_5_0_10_RELEASE</code>. This specifies the apex of the minibranch. For the 1.0.4 release, changes to that tag for Camino were made on a new <code>CAMINO_1_0_4_MINIBRANCH</code> branch, and the release tag was <code>CAMINO_1_0_4_RELEASE</code>. Camino branch and release tags follow this convention (<code>CAMINO_1_1_A2_MINIBRANCH</code>, <code>CAMINO_1_1_B_RELEASE</code>).

== 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 <code>-D</code> when checking out <code>client.mk</code>, and set <code>MOZ_CO_DATE</code> when making <code>client.mk</code>’s <code>checkout</code> 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 [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. (KaiRo has a [http://dev.seamonkey.at/?d=x&i=mozilla&m=t tool] that periodically queries tags, or you can use <code>cvs log</code> or perhaps even [http://bonsai.mozilla.org/cvsgraph.cgi?file=/mozilla/camino/config/version.txt bonsai] (or [http://bonsai.mozilla.org/cvsgraph.cgi?file=/mozilla/camino/resources/application/all-camino.js this link] for older branches) to find relevant Gecko tags.)

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). Note that we’ve been asked not to check in to this branch, even in <code>mozilla/camino</code>, so our own minibranch (below) is still needed.

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

In some cases, it’s not proper to base a Camino release off of an entire Gecko tree. For example, Camino 1.5.1 is based on <code>FIREFOX_2_0_0_6_RELEASE</code> in all directories except for <code>mozilla/camino</code>, which is based on then-current code from <code>CAMINO_1_5_BRANCH</code>. To switch the base in <code>mozilla/camino</code>, after the initial checkout above, do:

cvs update -r CAMINO_1_5_BRANCH -Pd camino

== Fork a minibranch ==

This can be done either by branching the entire checked-out tree, or branching individual files as needed. <code>client.mk</code> 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 <code>client.mk</code> if that’s all that’s changing. After branching, use <code>cvs update</code> 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 (<code>mozilla</code>).

cvs tag -b CAMINO_1_0_4_MINIBRANCH
cvs update -r CAMINO_1_0_4_MINIBRANCH

This usage only branches the individual files which will be modified from the base tag(s) for inclusion in the release tag:

cvs tag -b CAMINO_1_5_1_MINIBRANCH \
client.mk \
camino/Info-Camino.plist \
camino/Info-CaminoStatic.plist \
camino/resources/application/all-camino.js \
camino/resources/localized/English.lproj/InfoPlist.strings
cvs update -r CAMINO_1_5_1_MINIBRANCH \
client.mk \
camino/Info-Camino.plist \
camino/Info-CaminoStatic.plist \
camino/resources/application/all-camino.js \
camino/resources/localized/English.lproj/InfoPlist.strings

== Fix your (my) mistakes ==

At this point, I realized that the <code>FIREFOX_1_5_0_10_RELEASE</code> tag didn’t include changes to two Camino files that had been made recently on the <code>MOZILLA_1_8_0_BRANCH</code> in anticipation of Camino 1.0.4. I realized this because the release notes were missing. I found the other file by querying [http://bonsai.mozilla.org/ 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 <code>cvs tag -B -F</code> to move the tag because <code>ad_blocking.css</code> had already been branched. <code>cvs tag -B -F</code> 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 <code>client.mk</code> apply to the release tag ==

Now it’s possible to make changes to the working copy. First, update <code>client.mk</code> so that it will pull from the release tag (soon to be created). The relevant section of <code>client.mk</code> should look something like [http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/client.mk&rev=CAMINO_1_0_4_RELEASE&mark=241-245#236 this]. In this case, <code>sed</code> 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 <code>client.mk</code>. 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 [https://bugzilla.mozilla.org/buglist.cgi?status_whiteboard_type=substring&status_whiteboard=camino-1.0.3 querying Bugzilla for bugs with text like <code>camino-1.0.3</code>] in the status whiteboard field, by [http://bonsai.mozilla.org/cvsquery.cgi?branch=CAMINO_1_0_3_MINIBRANCH&date=all checking Bonsai for changes I made to the last release minibranch], or by asking [[User:Sardisson|Smokey]] or [[User:Admin|Sam]]. Those guys remember everything. These two things come from bugs [https://bugzilla.mozilla.org/show_bug.cgi?id=325765 325765] and [https://bugzilla.mozilla.org/show_bug.cgi?id=325964 325964]. When landing things on the minibranch, don’t forget to update the status whiteboard fields of the relevant bugs with text like <code>[camino-1.0.4]</code>.

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 [http://lxr.mozilla.org/mozilla/source/camino/docs/ReleaseChecklist.txt <code>camino/docs/ReleaseChecklist.txt</code>] 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 (<code>MOZILLA_1_8_0_BRANCH</code> 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+, but this versioning scheme is deprecated. Under the new scheme, the version number should be updated the the next version expected to be released from the branch, with “pre” appended. In this example, the version would be updated to 1.0.5pre. 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 <code>client.mk</code> 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 <code>client.mk</code> by the <code>CAMINO_1_0_4_RELEASE</code> tag, then they’ll get what they expect. Change the tags in <code>client.mk</code> 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.) This is only recommended if the entire tree was forked to make a minibranch, otherwise, it’s pointless. If using a Gecko release branch (recommended), you probably won’t have forked the entire tree for a minibranch, so this step is safe to skip.

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 used to be crappy and top-secret, and fortunately, it’s no longer necessary now that tinderbox can use <code>$UsePrebuiltTalkback</code>. The old procedure is included here to confuse you. We used to need to tag the Talkback tree too, so that tinderbox would get the right stuff. We only had access to that from the tinderbox itself. I’m not going to tell you what we used for <code>$CVSROOT</code>, but you could have found 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 <code>$BuildTag</code> in <code>tinder-config.pl</code> to make sure it corresponds to your chosen release tag (or branch). When building from a tag (instead of a branch), pull-by-timestamp (<code>cvs checkout -D</code>) must be turned off. It’s useful when building from branches. Its behavior is controlled by the <code>$UseTimeStamp</code> 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

Other significant variables affect the name displayed on the tinderbox status page, and the names of the directories created on the FTP server:

$BuildNameExtra = 'Cm1.0.4';
$milestone = "1.0.4";

Now, edit <code>multi-tinderbox</code>’ 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 <code>Cm1.0-M1.8.0</code> and adding a <code>Cm1.0.4</code> entry. Later, when the release is built, I’ll comment out <code>Cm1.0.4</code> and turn <code>Cm1.0-M1.8.0</code> back on. <code>multi-tinderbox</code> reloads its configuration when it receives a <code>SIGHUP</code>; 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 <code>multi-config.pl</code>.

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 <code>multi-tinderbox</code> to reload when the current build finishes:

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

When the release build begins, go to the [http://tinderbox.mozilla.org/Camino/ Camino tinderbox page], click “[http://tinderbox.mozilla.org/admintree.cgi?tree=Camino 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 your (my) mistakes|“fix-it”]] section above where I fixed <code>ad_blocking.css</code>, remembering that at this point, you’ve got both a <code>_MINIBRANCH</code> and <code>_RELEASE</code> 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 “[http://ftp.mozilla.org/pub/mozilla.org/camino/nightly/ nightly]” that tinderbox uploaded. If it seems reasonable, stage it and let people know. When possible, it’s nice to let the [http://caminol10n.mozdev.org/ 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 <code>/home/ftp/pub/camino/source/camino-1.0.4.tar.bz2</code>, and that directory has an <code>MD5SUMS</code> file as well. The multilingual release will go in
<code>/home/ftp/pub/camino/releases/Camino-1.0.4-MultiLang.dmg</code>, with a copy at <code>/home/ftp/pub/camino/releases/all/Camino-1.0.4.dmg</code>.

== Create a source release ==

We provide [http://ftp.mozilla.org/pub/mozilla.org/camino/source/ source tarballs] for major releases (not alphas, betas, or release candidates). Check out a fresh tree using anonymous CVS, so that the <code>CVS/Root</code> files are correct for people bootstrapping anonymous CVS workspaces. If the <code>.tar.bz2</code> 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|Stage it]].

== Have someone else set up Talkback reports ==

Ask Jay to set up [http://talkback-public.mozilla.org/reports/camino/ Talkback reports], at least until [http://code.google.com/p/google-breakpad/ 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 <code>Contents/MacOS/components/talkback/master.ini</code> file from <code>Camino.app</code> 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.

* Wait for mirror propagation from <code>stage.mozilla.org</code> to all of the systems handling <code>releases.mozilla.org</code>, <code>ftp.mozilla.org</code>, and other mirrors.
* Have someone on the build team update bouncer. [https://bugzilla.mozilla.org/enter_bug.cgi?product=mozilla.org&component=Build%20%26%20Release File a bug in the “mozilla.org:Build & Release” component], or e-mail [mailto:build@mozilla.org build@mozilla.org]. If you forget how to accomplish this step, ask Reed. He’s always happy to remind us.
* Someone’s got to [[Releases:Website Checklist|update the website]], the web site, or both.
* Some releases include a “release notes” URL that needs to be populated with content or a redirect. The release notes URL is defined as <code>ReleaseNotesDefault</code> in [http://lxr.mozilla.org/mozilla1.8.0/source/camino/resources/application/WebsiteDefaults.strings <code>camino/resources/application/WebsiteDefaults.strings</code>] and is updated as part of the [[#Release checklist|release checklist]]. The URL used in Camino 1.0.4 is [http://www.mozilla.org/products/camino/releases/1.0.4.html], which redirects to [http://www.caminobrowser.org/releases/1.0.4.php].

Development:Planning:Software Update

2007-08-22T17:48:15Z

Mento: /* Requirements */

==Requirements==
* can build in a 10.3/10.3.9 SDK/gcc3.3 and 10.4/10.4u/gcc4 Universal configuration
* Compatible license
* Approval to land in cvs (if not using mozUpdate) - mento prefers landing source code instead of binary drops
* https capabilities
** Everything needs to be either https or signed (signing is an option for the Sparkle downloads, but there's a logistical issue that would come with that)
* Update checking (OS version, etc.)
** say, 1.6.x updates to 2.0.x at some point unless you're running 10.3, in which case you only get 1.6.x updates
** and if you move to 10.4, do you get re-offered 2.0.x
* provide a way to turn off update checking from inside the app (unlike adium - with apologies to cbarrett for the jab)
* one thing i don't like about sparkle is that it doesn't check to see if you have permission to update the app first
* We should only enable update checking in official release builds

== Potential requirements==
* Resuming lost connections
* Background/throttled downloads?

==Concerns==
* QA
* Generation
* Gecko

Development:Planning:Software Update

2007-08-22T17:46:34Z

Mento: /* Requirements */

==Requirements==
* can build in a 10.3/10.3.9 SDK/gcc3.3 and 10.4/10.4u/gcc4 Universal configuration
* Compatible license
* Approval to land in cvs (if not using mozUpdate)
* https capabilities
** Everything needs to be either https or signed (signing is an option for the Sparkle downloads, but there's a logistical issue that would come with that)
* Update checking (OS version, etc.)
** say, 1.6.x updates to 2.0.x at some point unless you're running 10.3, in which case you only get 1.6.x updates
** and if you move to 10.4, do you get re-offered 2.0.x
* provide a way to turn off update checking from inside the app (unlike adium - with apologies to cbarrett for the jab)
* one thing i don't like about sparkle is that it doesn't check to see if you have permission to update the app first
* We should only enable update checking in official release builds

== Potential requirements==
* Resuming lost connections
* Background/throttled downloads?

==Concerns==
* QA
* Generation
* Gecko

Releases:Branch Tag Build Release

2007-08-10T19:23:18Z

Mento: /* Tag it */

<big>How to (branch and tag and build and) release a new version of Camino</big>
 
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 [http://www.caminobrowser.org/releases/1.0.4.php Camino 1.0.4] ([http://www.mozilla.com/en-US/firefox/releases/1.5.0.10.html Gecko 1.8.0.10]). The base tag for this release was <code>FIREFOX_1_5_0_10_RELEASE</code>. This specifies the apex of the minibranch. For the 1.0.4 release, changes to that tag for Camino were made on a new <code>CAMINO_1_0_4_MINIBRANCH</code> branch, and the release tag was <code>CAMINO_1_0_4_RELEASE</code>. Camino branch and release tags follow this convention (<code>CAMINO_1_1_A2_MINIBRANCH</code>, <code>CAMINO_1_1_B_RELEASE</code>).

== 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 <code>-D</code> when checking out <code>client.mk</code>, and set <code>MOZ_CO_DATE</code> when making <code>client.mk</code>’s <code>checkout</code> 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 [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. (KaiRo has a [http://dev.seamonkey.at/?d=x&i=mozilla&m=t tool] that periodically queries tags, or you can use <code>cvs log</code> or perhaps even [http://bonsai.mozilla.org/cvsgraph.cgi?file=/mozilla/camino/resources/application/all-camino.js bonsai] to find relevant Gecko tags.)

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). Note that we’ve been asked not to check in to this branch, even in <code>mozilla/camino</code>, so our own minibranch (below) is still needed.

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

In some cases, it’s not proper to base a Camino release off of an entire Gecko tree. For example, Camino 1.5.1 is based on <code>FIREFOX_2_0_0_6_RELEASE</code> in all directories except for <code>mozilla/camino</code>, which is based on then-current code from <code>CAMINO_1_5_BRANCH</code>. To switch the base in <code>mozilla/camino</code>, after the initial checkout above, do:

cvs update -r CAMINO_1_5_BRANCH -Pd camino

== Fork a minibranch ==

This can be done either by branching the entire checked-out tree, or branching individual files as needed. <code>client.mk</code> 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 <code>client.mk</code> if that’s all that’s changing. After branching, use <code>cvs update</code> 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 (<code>mozilla</code>).

cvs tag -b CAMINO_1_0_4_MINIBRANCH
cvs update -r CAMINO_1_0_4_MINIBRANCH

This usage only branches the individual files which will be modified from the base tag(s) for inclusion in the release tag:

cvs tag -b CAMINO_1_5_1_MINIBRANCH \
client.mk \
camino/Info-Camino.plist \
camino/Info-CaminoStatic.plist \
camino/resources/application/all-camino.js \
camino/resources/localized/English.lproj/InfoPlist.strings
cvs update -r CAMINO_1_5_1_MINIBRANCH \
client.mk \
camino/Info-Camino.plist \
camino/Info-CaminoStatic.plist \
camino/resources/application/all-camino.js \
camino/resources/localized/English.lproj/InfoPlist.strings

== Fix your (my) mistakes ==

At this point, I realized that the <code>FIREFOX_1_5_0_10_RELEASE</code> tag didn’t include changes to two Camino files that had been made recently on the <code>MOZILLA_1_8_0_BRANCH</code> in anticipation of Camino 1.0.4. I realized this because the release notes were missing. I found the other file by querying [http://bonsai.mozilla.org/ 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 <code>cvs tag -B -F</code> to move the tag because <code>ad_blocking.css</code> had already been branched. <code>cvs tag -B -F</code> 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 <code>client.mk</code> apply to the release tag ==

Now it’s possible to make changes to the working copy. First, update <code>client.mk</code> so that it will pull from the release tag (soon to be created). The relevant section of <code>client.mk</code> should look something like [http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/client.mk&rev=CAMINO_1_0_4_RELEASE&mark=241-245#236 this]. In this case, <code>sed</code> 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 <code>client.mk</code>. 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 [https://bugzilla.mozilla.org/buglist.cgi?status_whiteboard_type=substring&status_whiteboard=camino-1.0.3 querying Bugzilla for bugs with text like <code>camino-1.0.3</code>] in the status whiteboard field, by [http://bonsai.mozilla.org/cvsquery.cgi?branch=CAMINO_1_0_3_MINIBRANCH&date=all checking Bonsai for changes I made to the last release minibranch], or by asking [[User:Sardisson|Smokey]] or [[User:Admin|Sam]]. Those guys remember everything. These two things come from bugs [https://bugzilla.mozilla.org/show_bug.cgi?id=325765 325765] and [https://bugzilla.mozilla.org/show_bug.cgi?id=325964 325964]. When landing things on the minibranch, don’t forget to update the status whiteboard fields of the relevant bugs with text like <code>[camino-1.0.4]</code>.

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 [http://lxr.mozilla.org/mozilla/source/camino/docs/ReleaseChecklist.txt <code>camino/docs/ReleaseChecklist.txt</code>] 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 (<code>MOZILLA_1_8_0_BRANCH</code> 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+, but this versioning scheme is deprecated. Under the new scheme, the version number should be updated the the next version expected to be released from the branch, with “pre” appended. In this example, the version would be updated to 1.0.5pre. 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 <code>client.mk</code> 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 <code>client.mk</code> by the <code>CAMINO_1_0_4_RELEASE</code> tag, then they’ll get what they expect. Change the tags in <code>client.mk</code> 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.) This is only recommended if the entire tree was forked to make a minibranch, otherwise, it’s pointless. If using a Gecko release branch (recommended), you probably won’t have forked the entire tree for a minibranch, so this step is safe to skip.

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 used to be crappy and top-secret, and fortunately, it’s no longer necessary now that tinderbox can use <code>$UsePrebuiltTalkback</code>. The old procedure is included here to confuse you. We used to need to tag the Talkback tree too, so that tinderbox would get the right stuff. We only had access to that from the tinderbox itself. I’m not going to tell you what we used for <code>$CVSROOT</code>, but you could have found 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 <code>$BuildTag</code> in <code>tinder-config.pl</code> to make sure it corresponds to your chosen release tag (or branch). When building from a tag (instead of a branch), pull-by-timestamp (<code>cvs checkout -D</code>) must be turned off. It’s useful when building from branches. Its behavior is controlled by the <code>$UseTimeStamp</code> 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

Other significant variables affect the name displayed on the tinderbox status page, and the names of the directories created on the FTP server:

$BuildNameExtra = 'Cm1.0.4';
$milestone = "1.0.4";

Now, edit <code>multi-tinderbox</code>’ 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 <code>Cm1.0-M1.8.0</code> and adding a <code>Cm1.0.4</code> entry. Later, when the release is built, I’ll comment out <code>Cm1.0.4</code> and turn <code>Cm1.0-M1.8.0</code> back on. <code>multi-tinderbox</code> reloads its configuration when it receives a <code>SIGHUP</code>; 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 <code>multi-config.pl</code>.

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 <code>multi-tinderbox</code> to reload when the current build finishes:

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

When the release build begins, go to the [http://tinderbox.mozilla.org/Camino/ Camino tinderbox page], click “[http://tinderbox.mozilla.org/admintree.cgi?tree=Camino 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 your (my) mistakes|“fix-it”]] section above where I fixed <code>ad_blocking.css</code>, remembering that at this point, you’ve got both a <code>_MINIBRANCH</code> and <code>_RELEASE</code> 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 “[http://ftp.mozilla.org/pub/mozilla.org/camino/nightly/ nightly]” that tinderbox uploaded. If it seems reasonable, stage it and let people know. When possible, it’s nice to let the [http://caminol10n.mozdev.org/ 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 <code>/home/ftp/pub/camino/source/camino-1.0.4.tar.bz2</code>, and that directory has an <code>MD5SUMS</code> file as well. The multilingual release will go in
<code>/home/ftp/pub/camino/releases/Camino-1.0.4-MultiLang.dmg</code>, with a copy at <code>/home/ftp/pub/camino/releases/all/Camino-1.0.4.dmg</code>.

== Create a source release ==

We provide [http://ftp.mozilla.org/pub/mozilla.org/camino/source/ source tarballs] for major releases (not alphas, betas, or release candidates). Check out a fresh tree using anonymous CVS, so that the <code>CVS/Root</code> files are correct for people bootstrapping anonymous CVS workspaces. If the <code>.tar.bz2</code> 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|Stage it]].

== Have someone else set up Talkback reports ==

Ask Jay to set up [http://talkback-public.mozilla.org/reports/camino/ Talkback reports], at least until [http://code.google.com/p/google-breakpad/ 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 <code>Contents/MacOS/components/talkback/master.ini</code> file from <code>Camino.app</code> 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.

* Wait for mirror propagation from <code>stage.mozilla.org</code> to all of the systems handling <code>releases.mozilla.org</code>, <code>ftp.mozilla.org</code>, and other mirrors.
* Have someone on the build team update bouncer. [https://bugzilla.mozilla.org/enter_bug.cgi?product=mozilla.org&component=Build%20%26%20Release File a bug in the “mozilla.org:Build & Release” component], or e-mail [mailto:build@mozilla.org build@mozilla.org]. If you forget how to accomplish this step, ask Reed. He’s always happy to remind us.
* Someone’s got to [[Releases:Website Checklist|update the website]], the web site, or both.
* Some releases include a “release notes” URL that needs to be populated with content or a redirect. The release notes URL is defined as <code>ReleaseNotesDefault</code> in [http://lxr.mozilla.org/mozilla1.8.0/source/camino/resources/application/WebsiteDefaults.strings <code>camino/resources/application/WebsiteDefaults.strings</code>] and is updated as part of the [[#Release checklist|release checklist]]. The URL used in Camino 1.0.4 is [http://www.mozilla.org/products/camino/releases/1.0.4.html], which redirects to [http://www.caminobrowser.org/releases/1.0.4.php].

Releases:Branch Tag Build Release

2007-08-10T18:50:35Z

Mento:

<big>How to (branch and tag and build and) release a new version of Camino</big>
 
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 [http://www.caminobrowser.org/releases/1.0.4.php Camino 1.0.4] ([http://www.mozilla.com/en-US/firefox/releases/1.5.0.10.html Gecko 1.8.0.10]). The base tag for this release was <code>FIREFOX_1_5_0_10_RELEASE</code>. This specifies the apex of the minibranch. For the 1.0.4 release, changes to that tag for Camino were made on a new <code>CAMINO_1_0_4_MINIBRANCH</code> branch, and the release tag was <code>CAMINO_1_0_4_RELEASE</code>. Camino branch and release tags follow this convention (<code>CAMINO_1_1_A2_MINIBRANCH</code>, <code>CAMINO_1_1_B_RELEASE</code>).

== 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 <code>-D</code> when checking out <code>client.mk</code>, and set <code>MOZ_CO_DATE</code> when making <code>client.mk</code>’s <code>checkout</code> 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 [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. (KaiRo has a [http://dev.seamonkey.at/?d=x&i=mozilla&m=t tool] that periodically queries tags, or you can use <code>cvs log</code> or perhaps even [http://bonsai.mozilla.org/cvsgraph.cgi?file=/mozilla/camino/resources/application/all-camino.js bonsai] to find relevant Gecko tags.)

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). Note that we’ve been asked not to check in to this branch, even in <code>mozilla/camino</code>, so our own minibranch (below) is still needed.

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

In some cases, it’s not proper to base a Camino release off of an entire Gecko tree. For example, Camino 1.5.1 is based on <code>FIREFOX_2_0_0_6_RELEASE</code> in all directories except for <code>mozilla/camino</code>, which is based on then-current code from <code>CAMINO_1_5_BRANCH</code>. To switch the base in <code>mozilla/camino</code>, after the initial checkout above, do:

cvs update -r CAMINO_1_5_BRANCH -Pd camino

== Fork a minibranch ==

This can be done either by branching the entire checked-out tree, or branching individual files as needed. <code>client.mk</code> 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 <code>client.mk</code> if that’s all that’s changing. After branching, use <code>cvs update</code> 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 (<code>mozilla</code>).

cvs tag -b CAMINO_1_0_4_MINIBRANCH
cvs update -r CAMINO_1_0_4_MINIBRANCH

This usage only branches the individual files which will be modified from the base tag(s) for inclusion in the release tag:

cvs tag -b CAMINO_1_5_1_MINIBRANCH \
client.mk \
camino/Info-Camino.plist \
camino/Info-CaminoStatic.plist \
camino/resources/application/all-camino.js \
camino/resources/localized/English.lproj/InfoPlist.strings
cvs update -r CAMINO_1_5_1_MINIBRANCH \
client.mk \
camino/Info-Camino.plist \
camino/Info-CaminoStatic.plist \
camino/resources/application/all-camino.js \
camino/resources/localized/English.lproj/InfoPlist.strings

== Fix your (my) mistakes ==

At this point, I realized that the <code>FIREFOX_1_5_0_10_RELEASE</code> tag didn’t include changes to two Camino files that had been made recently on the <code>MOZILLA_1_8_0_BRANCH</code> in anticipation of Camino 1.0.4. I realized this because the release notes were missing. I found the other file by querying [http://bonsai.mozilla.org/ 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 <code>cvs tag -B -F</code> to move the tag because <code>ad_blocking.css</code> had already been branched. <code>cvs tag -B -F</code> 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 <code>client.mk</code> apply to the release tag ==

Now it’s possible to make changes to the working copy. First, update <code>client.mk</code> so that it will pull from the release tag (soon to be created). The relevant section of <code>client.mk</code> should look something like [http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/client.mk&rev=CAMINO_1_0_4_RELEASE&mark=241-245#236 this]. In this case, <code>sed</code> 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 <code>client.mk</code>. 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 [https://bugzilla.mozilla.org/buglist.cgi?status_whiteboard_type=substring&status_whiteboard=camino-1.0.3 querying Bugzilla for bugs with text like <code>camino-1.0.3</code>] in the status whiteboard field, by [http://bonsai.mozilla.org/cvsquery.cgi?branch=CAMINO_1_0_3_MINIBRANCH&date=all checking Bonsai for changes I made to the last release minibranch], or by asking [[User:Sardisson|Smokey]] or [[User:Admin|Sam]]. Those guys remember everything. These two things come from bugs [https://bugzilla.mozilla.org/show_bug.cgi?id=325765 325765] and [https://bugzilla.mozilla.org/show_bug.cgi?id=325964 325964]. When landing things on the minibranch, don’t forget to update the status whiteboard fields of the relevant bugs with text like <code>[camino-1.0.4]</code>.

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 [http://lxr.mozilla.org/mozilla/source/camino/docs/ReleaseChecklist.txt <code>camino/docs/ReleaseChecklist.txt</code>] 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 (<code>MOZILLA_1_8_0_BRANCH</code> 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+, but this versioning scheme is deprecated. Under the new scheme, the version number should be updated the the next version expected to be released from the branch, with “pre” appended. In this example, the version would be updated to 1.0.5pre. 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 <code>client.mk</code> 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 <code>client.mk</code> by the <code>CAMINO_1_0_4_RELEASE</code> tag, then they’ll get what they expect. Change the tags in <code>client.mk</code> 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.) This is only recommended if the entire tree was forked to make a minibranch, otherwise, it’s pointless. If using a Gecko release branch (recommended), you probably won’t have forked the entire tree for a minibranch, so this step is safe to skip.

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 <code>$CVSROOT</code>, 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 <code>$BuildTag</code> in <code>tinder-config.pl</code> to make sure it corresponds to your chosen release tag (or branch). When building from a tag (instead of a branch), pull-by-timestamp (<code>cvs checkout -D</code>) must be turned off. It’s useful when building from branches. Its behavior is controlled by the <code>$UseTimeStamp</code> 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

Other significant variables affect the name displayed on the tinderbox status page, and the names of the directories created on the FTP server:

$BuildNameExtra = 'Cm1.0.4';
$milestone = "1.0.4";

Now, edit <code>multi-tinderbox</code>’ 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 <code>Cm1.0-M1.8.0</code> and adding a <code>Cm1.0.4</code> entry. Later, when the release is built, I’ll comment out <code>Cm1.0.4</code> and turn <code>Cm1.0-M1.8.0</code> back on. <code>multi-tinderbox</code> reloads its configuration when it receives a <code>SIGHUP</code>; 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 <code>multi-config.pl</code>.

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 <code>multi-tinderbox</code> to reload when the current build finishes:

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

When the release build begins, go to the [http://tinderbox.mozilla.org/Camino/ Camino tinderbox page], click “[http://tinderbox.mozilla.org/admintree.cgi?tree=Camino 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 your (my) mistakes|“fix-it”]] section above where I fixed <code>ad_blocking.css</code>, remembering that at this point, you’ve got both a <code>_MINIBRANCH</code> and <code>_RELEASE</code> 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 “[http://ftp.mozilla.org/pub/mozilla.org/camino/nightly/ nightly]” that tinderbox uploaded. If it seems reasonable, stage it and let people know. When possible, it’s nice to let the [http://caminol10n.mozdev.org/ 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 <code>/home/ftp/pub/camino/source/camino-1.0.4.tar.bz2</code>, and that directory has an <code>MD5SUMS</code> file as well. The multilingual release will go in
<code>/home/ftp/pub/camino/releases/Camino-1.0.4-MultiLang.dmg</code>, with a copy at <code>/home/ftp/pub/camino/releases/all/Camino-1.0.4.dmg</code>.

== Create a source release ==

We provide [http://ftp.mozilla.org/pub/mozilla.org/camino/source/ source tarballs] for major releases (not alphas, betas, or release candidates). Check out a fresh tree using anonymous CVS, so that the <code>CVS/Root</code> files are correct for people bootstrapping anonymous CVS workspaces. If the <code>.tar.bz2</code> 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|Stage it]].

== Have someone else set up Talkback reports ==

Ask Jay to set up [http://talkback-public.mozilla.org/reports/camino/ Talkback reports], at least until [http://code.google.com/p/google-breakpad/ 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 <code>Contents/MacOS/components/talkback/master.ini</code> file from <code>Camino.app</code> 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.

* Wait for mirror propagation from <code>stage.mozilla.org</code> to all of the systems handling <code>releases.mozilla.org</code>, <code>ftp.mozilla.org</code>, and other mirrors.
* Have someone on the build team update bouncer. [https://bugzilla.mozilla.org/enter_bug.cgi?product=mozilla.org&component=Build%20%26%20Release File a bug in the “mozilla.org:Build & Release” component], or e-mail [mailto:build@mozilla.org build@mozilla.org]. If you forget how to accomplish this step, ask Reed. He’s always happy to remind us.
* Someone’s got to [[Releases:Website Checklist|update the website]], the web site, or both.
* Some releases include a “release notes” URL that needs to be populated with content or a redirect. The release notes URL is defined as <code>ReleaseNotesDefault</code> in [http://lxr.mozilla.org/mozilla1.8.0/source/camino/resources/application/WebsiteDefaults.strings <code>camino/resources/application/WebsiteDefaults.strings</code>] and is updated as part of the [[#Release checklist|release checklist]]. The URL used in Camino 1.0.4 is [http://www.mozilla.org/products/camino/releases/1.0.4.html], which redirects to [http://www.caminobrowser.org/releases/1.0.4.php].

Releases:Branch Tag Build Release

2007-08-10T18:46:22Z

Mento: /* Fork a minibranch */

<big>How to (branch and tag and build and) release a new version of Camino</big>
 
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 [http://www.caminobrowser.org/releases/1.0.4.php Camino 1.0.4] ([http://www.mozilla.com/en-US/firefox/releases/1.5.0.10.html Gecko 1.8.0.10]). The base tag for this release was <code>FIREFOX_1_5_0_10_RELEASE</code>. This specifies the apex of the minibranch. For the 1.0.4 release, changes to that tag for Camino were made on a new <code>CAMINO_1_0_4_MINIBRANCH</code> branch, and the release tag was <code>CAMINO_1_0_4_RELEASE</code>. Camino branch and release tags follow this convention (<code>CAMINO_1_1_A2_MINIBRANCH</code>, <code>CAMINO_1_1_B_RELEASE</code>).

== 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 <code>-D</code> when checking out <code>client.mk</code>, and set <code>MOZ_CO_DATE</code> when making <code>client.mk</code>’s <code>checkout</code> 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 [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. (KaiRo has a [http://dev.seamonkey.at/?d=x&i=mozilla&m=t tool] that periodically queries tags, or you can use <code>cvs log</code> or perhaps even [http://bonsai.mozilla.org/cvsgraph.cgi?file=/mozilla/camino/resources/application/all-camino.js bonsai] to find relevant Gecko tags.)

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). Note that we’ve been asked not to check in to this branch, even in <code>mozilla/camino</code>, so our own minibranch (below) is still needed.

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

In some cases, it’s not proper to base a Camino release off of an entire Gecko tree. For example, Camino 1.5.1 is based on <code>FIREFOX_2_0_0_6_RELEASE</code> in all directories except for <code>mozilla/camino</code>, which is based on then-current code from <code>CAMINO_1_5_BRANCH</code>. To switch the base in <code>mozilla/camino</code>, after the initial checkout above, do:

cvs update -r CAMINO_1_5_BRANCH -Pd camino

== Fork a minibranch ==

This can be done either by branching the entire checked-out tree, or branching individual files as needed. <code>client.mk</code> 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 <code>client.mk</code> if that’s all that’s changing. After branching, use <code>cvs update</code> 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 (<code>mozilla</code>).

cvs tag -b CAMINO_1_0_4_MINIBRANCH
cvs update -r CAMINO_1_0_4_MINIBRANCH

This usage only branches the individual files which will be modified from the base tag(s) for inclusion in the release tag:

cvs tag -b CAMINO_1_5_1_MINIBRANCH \
client.mk \
camino/Info-Camino.plist \
camino/Info-CaminoStatic.plist \
camino/resources/application/all-camino.js \
camino/resources/localized/English.lproj/InfoPlist.strings
cvs update -r CAMINO_1_5_1_MINIBRANCH \
client.mk \
camino/Info-Camino.plist \
camino/Info-CaminoStatic.plist \
camino/resources/application/all-camino.js \
camino/resources/localized/English.lproj/InfoPlist.strings

== Fix your (my) mistakes ==

At this point, I realized that the <code>FIREFOX_1_5_0_10_RELEASE</code> tag didn’t include changes to two Camino files that had been made recently on the <code>MOZILLA_1_8_0_BRANCH</code> in anticipation of Camino 1.0.4. I realized this because the release notes were missing. I found the other file by querying [http://bonsai.mozilla.org/ 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 <code>cvs tag -B -F</code> to move the tag because <code>ad_blocking.css</code> had already been branched. <code>cvs tag -B -F</code> 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 <code>client.mk</code> apply to the release tag ==

Now it’s possible to make changes to the working copy. First, update <code>client.mk</code> so that it will pull from the release tag (soon to be created). The relevant section of <code>client.mk</code> should look something like [http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/client.mk&rev=CAMINO_1_0_4_RELEASE&mark=241-245#236 this]. In this case, <code>sed</code> 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 <code>client.mk</code>. 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 [https://bugzilla.mozilla.org/buglist.cgi?status_whiteboard_type=substring&status_whiteboard=camino-1.0.3 querying Bugzilla for bugs with text like <code>camino-1.0.3</code>] in the status whiteboard field, by [http://bonsai.mozilla.org/cvsquery.cgi?branch=CAMINO_1_0_3_MINIBRANCH&date=all checking Bonsai for changes I made to the last release minibranch], or by asking [[User:Sardisson|Smokey]] or [[User:Admin|Sam]]. Those guys remember everything. These two things come from bugs [https://bugzilla.mozilla.org/show_bug.cgi?id=325765 325765] and [https://bugzilla.mozilla.org/show_bug.cgi?id=325964 325964]. When landing things on the minibranch, don’t forget to update the status whiteboard fields of the relevant bugs with text like <code>[camino-1.0.4]</code>.

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 [http://lxr.mozilla.org/mozilla/source/camino/docs/ReleaseChecklist.txt <code>camino/docs/ReleaseChecklist.txt</code>] 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 (<code>MOZILLA_1_8_0_BRANCH</code> 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+, but this versioning scheme is deprecated. Under the new scheme, the version number should be updated the the next version expected to be released from the branch, with “pre” appended. In this example, the version would be updated to 1.0.5pre. 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 <code>client.mk</code> 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 <code>client.mk</code> by the <code>CAMINO_1_0_4_RELEASE</code> tag, then they’ll get what they expect. Change the tags in <code>client.mk</code> 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.) This is only recommended if the entire tree was forked to make a minibranch, otherwise, it's pointless. If using a Gecko release branch (recommended), you probably won't have forked the entire tree for a minibranch, so this step is safe to skip.

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 <code>$CVSROOT</code>, 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 <code>$BuildTag</code> in <code>tinder-config.pl</code> to make sure it corresponds to your chosen release tag (or branch). When building from a tag (instead of a branch), pull-by-timestamp (<code>cvs checkout -D</code>) must be turned off. It’s useful when building from branches. Its behavior is controlled by the <code>$UseTimeStamp</code> 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

Other significant variables affect the name displayed on the tinderbox status page, and the names of the directories created on the FTP server:

$BuildNameExtra = 'Cm1.0.4';
$milestone = "1.0.4";

Now, edit <code>multi-tinderbox</code>’ 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 <code>Cm1.0-M1.8.0</code> and adding a <code>Cm1.0.4</code> entry. Later, when the release is built, I’ll comment out <code>Cm1.0.4</code> and turn <code>Cm1.0-M1.8.0</code> back on. <code>multi-tinderbox</code> reloads its configuration when it receives a <code>SIGHUP</code>; 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 <code>multi-config.pl</code>.

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 <code>multi-tinderbox</code> to reload when the current build finishes:

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

When the release build begins, go to the [http://tinderbox.mozilla.org/Camino/ Camino tinderbox page], click “[http://tinderbox.mozilla.org/admintree.cgi?tree=Camino 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 your (my) mistakes|“fix-it”]] section above where I fixed <code>ad_blocking.css</code>, remembering that at this point, you’ve got both a <code>_MINIBRANCH</code> and <code>_RELEASE</code> 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 “[http://ftp.mozilla.org/pub/mozilla.org/camino/nightly/ nightly]” that tinderbox uploaded. If it seems reasonable, stage it and let people know. When possible, it’s nice to let the [http://caminol10n.mozdev.org/ 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 <code>/home/ftp/pub/camino/source/camino-1.0.4.tar.bz2</code>, and that directory has an <code>MD5SUMS</code> file as well. The multilingual release will go in
<code>/home/ftp/pub/camino/releases/Camino-1.0.4-MultiLang.dmg</code>, with a copy at <code>/home/ftp/pub/camino/releases/all/Camino-1.0.4.dmg</code>.

== Create a source release ==

We provide [http://ftp.mozilla.org/pub/mozilla.org/camino/source/ source tarballs] for major releases (not alphas, betas, or release candidates). Check out a fresh tree using anonymous CVS, so that the <code>CVS/Root</code> files are correct for people bootstrapping anonymous CVS workspaces. If the <code>.tar.bz2</code> 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|Stage it]].

== Have someone else set up Talkback reports ==

Ask Jay to set up [http://talkback-public.mozilla.org/reports/camino/ Talkback reports], at least until [http://code.google.com/p/google-breakpad/ 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 <code>Contents/MacOS/components/talkback/master.ini</code> file from <code>Camino.app</code> 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.

* Wait for mirror propagation from <code>stage.mozilla.org</code> to all of the systems handling <code>releases.mozilla.org</code>, <code>ftp.mozilla.org</code>, and other mirrors.
* Have someone on the build team update bouncer. [https://bugzilla.mozilla.org/enter_bug.cgi?product=mozilla.org&component=Build%20%26%20Release File a bug in the “mozilla.org:Build & Release” component], or e-mail [mailto:build@mozilla.org build@mozilla.org]. If you forget how to accomplish this step, ask Reed. He’s always happy to remind us.
* Someone’s got to [[Releases:Website Checklist|update the website]], the web site, or both.
* Some releases include a “release notes” URL that needs to be populated with content or a redirect. The release notes URL is defined as <code>ReleaseNotesDefault</code> in [http://lxr.mozilla.org/mozilla1.8.0/source/camino/resources/application/WebsiteDefaults.strings <code>camino/resources/application/WebsiteDefaults.strings</code>] and is updated as part of the [[#Release checklist|release checklist]]. The URL used in Camino 1.0.4 is [http://www.mozilla.org/products/camino/releases/1.0.4.html], which redirects to [http://www.caminobrowser.org/releases/1.0.4.php].

Releases:Branch Tag Build Release

2007-08-10T18:40:20Z

Mento: /* Check out the source */

<big>How to (branch and tag and build and) release a new version of Camino</big>
 
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 [http://www.caminobrowser.org/releases/1.0.4.php Camino 1.0.4] ([http://www.mozilla.com/en-US/firefox/releases/1.5.0.10.html Gecko 1.8.0.10]). The base tag for this release was <code>FIREFOX_1_5_0_10_RELEASE</code>. This specifies the apex of the minibranch. For the 1.0.4 release, changes to that tag for Camino were made on a new <code>CAMINO_1_0_4_MINIBRANCH</code> branch, and the release tag was <code>CAMINO_1_0_4_RELEASE</code>. Camino branch and release tags follow this convention (<code>CAMINO_1_1_A2_MINIBRANCH</code>, <code>CAMINO_1_1_B_RELEASE</code>).

== 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 <code>-D</code> when checking out <code>client.mk</code>, and set <code>MOZ_CO_DATE</code> when making <code>client.mk</code>’s <code>checkout</code> 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 [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. (KaiRo has a [http://dev.seamonkey.at/?d=x&i=mozilla&m=t tool] that periodically queries tags, or you can use <code>cvs log</code> or perhaps even [http://bonsai.mozilla.org/cvsgraph.cgi?file=/mozilla/camino/resources/application/all-camino.js bonsai] to find relevant Gecko tags.)

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). Note that we’ve been asked not to check in to this branch, even in <code>mozilla/camino</code>, so our own minibranch (below) is still needed.

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

In some cases, it’s not proper to base a Camino release off of an entire Gecko tree. For example, Camino 1.5.1 is based on <code>FIREFOX_2_0_0_6_RELEASE</code> in all directories except for <code>mozilla/camino</code>, which is based on then-current code from <code>CAMINO_1_5_BRANCH</code>. To switch the base in <code>mozilla/camino</code>, after the initial checkout above, do:

cvs update -r CAMINO_1_5_BRANCH -Pd camino

== Fork a minibranch ==

This can be done either by branching the entire checked-out tree, or branching individual files as needed. <code>client.mk</code> 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 <code>client.mk</code> if that’s all that’s changing. After branching, use <code>cvs update</code> 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 (<code>mozilla</code>). 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

If using a <code>GECKOver_date_RELBRANCH</code> branch (recommended), the best practice is to only minibranch <code>client.mk</code>, and to use the Gecko release branch for any other files that need to change. For example:

cvs tag -b CAMINO_1_5_MINIBRANCH client.mk
cvs update -r CAMINO_1_5_MINIBRANCH client.mk
cvs update -r GECKO181_20070501_RELBRANCH camino # to allow files in mozilla/camino to be updated

== Fix your (my) mistakes ==

At this point, I realized that the <code>FIREFOX_1_5_0_10_RELEASE</code> tag didn’t include changes to two Camino files that had been made recently on the <code>MOZILLA_1_8_0_BRANCH</code> in anticipation of Camino 1.0.4. I realized this because the release notes were missing. I found the other file by querying [http://bonsai.mozilla.org/ 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 <code>cvs tag -B -F</code> to move the tag because <code>ad_blocking.css</code> had already been branched. <code>cvs tag -B -F</code> 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 <code>client.mk</code> apply to the release tag ==

Now it’s possible to make changes to the working copy. First, update <code>client.mk</code> so that it will pull from the release tag (soon to be created). The relevant section of <code>client.mk</code> should look something like [http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/client.mk&rev=CAMINO_1_0_4_RELEASE&mark=241-245#236 this]. In this case, <code>sed</code> 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 <code>client.mk</code>. 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 [https://bugzilla.mozilla.org/buglist.cgi?status_whiteboard_type=substring&status_whiteboard=camino-1.0.3 querying Bugzilla for bugs with text like <code>camino-1.0.3</code>] in the status whiteboard field, by [http://bonsai.mozilla.org/cvsquery.cgi?branch=CAMINO_1_0_3_MINIBRANCH&date=all checking Bonsai for changes I made to the last release minibranch], or by asking [[User:Sardisson|Smokey]] or [[User:Admin|Sam]]. Those guys remember everything. These two things come from bugs [https://bugzilla.mozilla.org/show_bug.cgi?id=325765 325765] and [https://bugzilla.mozilla.org/show_bug.cgi?id=325964 325964]. When landing things on the minibranch, don’t forget to update the status whiteboard fields of the relevant bugs with text like <code>[camino-1.0.4]</code>.

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 [http://lxr.mozilla.org/mozilla/source/camino/docs/ReleaseChecklist.txt <code>camino/docs/ReleaseChecklist.txt</code>] 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 (<code>MOZILLA_1_8_0_BRANCH</code> 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+, but this versioning scheme is deprecated. Under the new scheme, the version number should be updated the the next version expected to be released from the branch, with “pre” appended. In this example, the version would be updated to 1.0.5pre. 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 <code>client.mk</code> 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 <code>client.mk</code> by the <code>CAMINO_1_0_4_RELEASE</code> tag, then they’ll get what they expect. Change the tags in <code>client.mk</code> 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.) This is only recommended if the entire tree was forked to make a minibranch, otherwise, it's pointless. If using a Gecko release branch (recommended), you probably won't have forked the entire tree for a minibranch, so this step is safe to skip.

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 <code>$CVSROOT</code>, 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 <code>$BuildTag</code> in <code>tinder-config.pl</code> to make sure it corresponds to your chosen release tag (or branch). When building from a tag (instead of a branch), pull-by-timestamp (<code>cvs checkout -D</code>) must be turned off. It’s useful when building from branches. Its behavior is controlled by the <code>$UseTimeStamp</code> 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

Other significant variables affect the name displayed on the tinderbox status page, and the names of the directories created on the FTP server:

$BuildNameExtra = 'Cm1.0.4';
$milestone = "1.0.4";

Now, edit <code>multi-tinderbox</code>’ 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 <code>Cm1.0-M1.8.0</code> and adding a <code>Cm1.0.4</code> entry. Later, when the release is built, I’ll comment out <code>Cm1.0.4</code> and turn <code>Cm1.0-M1.8.0</code> back on. <code>multi-tinderbox</code> reloads its configuration when it receives a <code>SIGHUP</code>; 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 <code>multi-config.pl</code>.

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 <code>multi-tinderbox</code> to reload when the current build finishes:

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

When the release build begins, go to the [http://tinderbox.mozilla.org/Camino/ Camino tinderbox page], click “[http://tinderbox.mozilla.org/admintree.cgi?tree=Camino 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 your (my) mistakes|“fix-it”]] section above where I fixed <code>ad_blocking.css</code>, remembering that at this point, you’ve got both a <code>_MINIBRANCH</code> and <code>_RELEASE</code> 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 “[http://ftp.mozilla.org/pub/mozilla.org/camino/nightly/ nightly]” that tinderbox uploaded. If it seems reasonable, stage it and let people know. When possible, it’s nice to let the [http://caminol10n.mozdev.org/ 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 <code>/home/ftp/pub/camino/source/camino-1.0.4.tar.bz2</code>, and that directory has an <code>MD5SUMS</code> file as well. The multilingual release will go in
<code>/home/ftp/pub/camino/releases/Camino-1.0.4-MultiLang.dmg</code>, with a copy at <code>/home/ftp/pub/camino/releases/all/Camino-1.0.4.dmg</code>.

== Create a source release ==

We provide [http://ftp.mozilla.org/pub/mozilla.org/camino/source/ source tarballs] for major releases (not alphas, betas, or release candidates). Check out a fresh tree using anonymous CVS, so that the <code>CVS/Root</code> files are correct for people bootstrapping anonymous CVS workspaces. If the <code>.tar.bz2</code> 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|Stage it]].

== Have someone else set up Talkback reports ==

Ask Jay to set up [http://talkback-public.mozilla.org/reports/camino/ Talkback reports], at least until [http://code.google.com/p/google-breakpad/ 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 <code>Contents/MacOS/components/talkback/master.ini</code> file from <code>Camino.app</code> 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.

* Wait for mirror propagation from <code>stage.mozilla.org</code> to all of the systems handling <code>releases.mozilla.org</code>, <code>ftp.mozilla.org</code>, and other mirrors.
* Have someone on the build team update bouncer. [https://bugzilla.mozilla.org/enter_bug.cgi?product=mozilla.org&component=Build%20%26%20Release File a bug in the “mozilla.org:Build & Release” component], or e-mail [mailto:build@mozilla.org build@mozilla.org]. If you forget how to accomplish this step, ask Reed. He’s always happy to remind us.
* Someone’s got to [[Releases:Website Checklist|update the website]], the web site, or both.
* Some releases include a “release notes” URL that needs to be populated with content or a redirect. The release notes URL is defined as <code>ReleaseNotesDefault</code> in [http://lxr.mozilla.org/mozilla1.8.0/source/camino/resources/application/WebsiteDefaults.strings <code>camino/resources/application/WebsiteDefaults.strings</code>] and is updated as part of the [[#Release checklist|release checklist]]. The URL used in Camino 1.0.4 is [http://www.mozilla.org/products/camino/releases/1.0.4.html], which redirects to [http://www.caminobrowser.org/releases/1.0.4.php].

Releases:Branch Tag Build Release

2007-08-10T18:37:03Z

Mento: /* Check out the source */

<big>How to (branch and tag and build and) release a new version of Camino</big>
 
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 [http://www.caminobrowser.org/releases/1.0.4.php Camino 1.0.4] ([http://www.mozilla.com/en-US/firefox/releases/1.5.0.10.html Gecko 1.8.0.10]). The base tag for this release was <code>FIREFOX_1_5_0_10_RELEASE</code>. This specifies the apex of the minibranch. For the 1.0.4 release, changes to that tag for Camino were made on a new <code>CAMINO_1_0_4_MINIBRANCH</code> branch, and the release tag was <code>CAMINO_1_0_4_RELEASE</code>. Camino branch and release tags follow this convention (<code>CAMINO_1_1_A2_MINIBRANCH</code>, <code>CAMINO_1_1_B_RELEASE</code>).

== 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 <code>-D</code> when checking out <code>client.mk</code>, and set <code>MOZ_CO_DATE</code> when making <code>client.mk</code>’s <code>checkout</code> 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 [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. (KaiRo has a [http://dev.seamonkey.at/?d=x&i=mozilla&m=t tool] that periodically queries tags, or you can use <code>cvs log</code> or perhaps even [http://bonsai.mozilla.org/cvsgraph.cgi?file=/mozilla/camino/resources/application/all-camino.js bonsai] to find relevant Gecko tags.)

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). Note that we've been asked not to check in to this branch, even in <code>mozilla/camino</code>, so our own minibranch (below) is still needed.

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. <code>client.mk</code> 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 <code>client.mk</code> if that’s all that’s changing. After branching, use <code>cvs update</code> 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 (<code>mozilla</code>). 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

If using a <code>GECKOver_date_RELBRANCH</code> branch (recommended), the best practice is to only minibranch <code>client.mk</code>, and to use the Gecko release branch for any other files that need to change. For example:

cvs tag -b CAMINO_1_5_MINIBRANCH client.mk
cvs update -r CAMINO_1_5_MINIBRANCH client.mk
cvs update -r GECKO181_20070501_RELBRANCH camino # to allow files in mozilla/camino to be updated

== Fix your (my) mistakes ==

At this point, I realized that the <code>FIREFOX_1_5_0_10_RELEASE</code> tag didn’t include changes to two Camino files that had been made recently on the <code>MOZILLA_1_8_0_BRANCH</code> in anticipation of Camino 1.0.4. I realized this because the release notes were missing. I found the other file by querying [http://bonsai.mozilla.org/ 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 <code>cvs tag -B -F</code> to move the tag because <code>ad_blocking.css</code> had already been branched. <code>cvs tag -B -F</code> 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 <code>client.mk</code> apply to the release tag ==

Now it’s possible to make changes to the working copy. First, update <code>client.mk</code> so that it will pull from the release tag (soon to be created). The relevant section of <code>client.mk</code> should look something like [http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/client.mk&rev=CAMINO_1_0_4_RELEASE&mark=241-245#236 this]. In this case, <code>sed</code> 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 <code>client.mk</code>. 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 [https://bugzilla.mozilla.org/buglist.cgi?status_whiteboard_type=substring&status_whiteboard=camino-1.0.3 querying Bugzilla for bugs with text like <code>camino-1.0.3</code>] in the status whiteboard field, by [http://bonsai.mozilla.org/cvsquery.cgi?branch=CAMINO_1_0_3_MINIBRANCH&date=all checking Bonsai for changes I made to the last release minibranch], or by asking [[User:Sardisson|Smokey]] or [[User:Admin|Sam]]. Those guys remember everything. These two things come from bugs [https://bugzilla.mozilla.org/show_bug.cgi?id=325765 325765] and [https://bugzilla.mozilla.org/show_bug.cgi?id=325964 325964]. When landing things on the minibranch, don’t forget to update the status whiteboard fields of the relevant bugs with text like <code>[camino-1.0.4]</code>.

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 [http://lxr.mozilla.org/mozilla/source/camino/docs/ReleaseChecklist.txt <code>camino/docs/ReleaseChecklist.txt</code>] 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 (<code>MOZILLA_1_8_0_BRANCH</code> 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+, but this versioning scheme is deprecated. Under the new scheme, the version number should be updated the the next version expected to be released from the branch, with “pre” appended. In this example, the version would be updated to 1.0.5pre. 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 <code>client.mk</code> 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 <code>client.mk</code> by the <code>CAMINO_1_0_4_RELEASE</code> tag, then they’ll get what they expect. Change the tags in <code>client.mk</code> 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.) This is only recommended if the entire tree was forked to make a minibranch, otherwise, it's pointless. If using a Gecko release branch (recommended), you probably won't have forked the entire tree for a minibranch, so this step is safe to skip.

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 <code>$CVSROOT</code>, 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 <code>$BuildTag</code> in <code>tinder-config.pl</code> to make sure it corresponds to your chosen release tag (or branch). When building from a tag (instead of a branch), pull-by-timestamp (<code>cvs checkout -D</code>) must be turned off. It’s useful when building from branches. Its behavior is controlled by the <code>$UseTimeStamp</code> 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

Other significant variables affect the name displayed on the tinderbox status page, and the names of the directories created on the FTP server:

$BuildNameExtra = 'Cm1.0.4';
$milestone = "1.0.4";

Now, edit <code>multi-tinderbox</code>’ 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 <code>Cm1.0-M1.8.0</code> and adding a <code>Cm1.0.4</code> entry. Later, when the release is built, I’ll comment out <code>Cm1.0.4</code> and turn <code>Cm1.0-M1.8.0</code> back on. <code>multi-tinderbox</code> reloads its configuration when it receives a <code>SIGHUP</code>; 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 <code>multi-config.pl</code>.

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 <code>multi-tinderbox</code> to reload when the current build finishes:

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

When the release build begins, go to the [http://tinderbox.mozilla.org/Camino/ Camino tinderbox page], click “[http://tinderbox.mozilla.org/admintree.cgi?tree=Camino 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 your (my) mistakes|“fix-it”]] section above where I fixed <code>ad_blocking.css</code>, remembering that at this point, you’ve got both a <code>_MINIBRANCH</code> and <code>_RELEASE</code> 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 “[http://ftp.mozilla.org/pub/mozilla.org/camino/nightly/ nightly]” that tinderbox uploaded. If it seems reasonable, stage it and let people know. When possible, it’s nice to let the [http://caminol10n.mozdev.org/ 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 <code>/home/ftp/pub/camino/source/camino-1.0.4.tar.bz2</code>, and that directory has an <code>MD5SUMS</code> file as well. The multilingual release will go in
<code>/home/ftp/pub/camino/releases/Camino-1.0.4-MultiLang.dmg</code>, with a copy at <code>/home/ftp/pub/camino/releases/all/Camino-1.0.4.dmg</code>.

== Create a source release ==

We provide [http://ftp.mozilla.org/pub/mozilla.org/camino/source/ source tarballs] for major releases (not alphas, betas, or release candidates). Check out a fresh tree using anonymous CVS, so that the <code>CVS/Root</code> files are correct for people bootstrapping anonymous CVS workspaces. If the <code>.tar.bz2</code> 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|Stage it]].

== Have someone else set up Talkback reports ==

Ask Jay to set up [http://talkback-public.mozilla.org/reports/camino/ Talkback reports], at least until [http://code.google.com/p/google-breakpad/ 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 <code>Contents/MacOS/components/talkback/master.ini</code> file from <code>Camino.app</code> 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.

* Wait for mirror propagation from <code>stage.mozilla.org</code> to all of the systems handling <code>releases.mozilla.org</code>, <code>ftp.mozilla.org</code>, and other mirrors.
* Have someone on the build team update bouncer. [https://bugzilla.mozilla.org/enter_bug.cgi?product=mozilla.org&component=Build%20%26%20Release File a bug in the “mozilla.org:Build & Release” component], or e-mail [mailto:build@mozilla.org build@mozilla.org]. If you forget how to accomplish this step, ask Reed. He’s always happy to remind us.
* Someone’s got to [[Releases:Website Checklist|update the website]], the web site, or both.
* Some releases include a “release notes” URL that needs to be populated with content or a redirect. The release notes URL is defined as <code>ReleaseNotesDefault</code> in [http://lxr.mozilla.org/mozilla1.8.0/source/camino/resources/application/WebsiteDefaults.strings <code>camino/resources/application/WebsiteDefaults.strings</code>] and is updated as part of the [[#Release checklist|release checklist]]. The URL used in Camino 1.0.4 is [http://www.mozilla.org/products/camino/releases/1.0.4.html], which redirects to [http://www.caminobrowser.org/releases/1.0.4.php].

Status Meetings:2007-06-06:Agenda

2007-06-06T16:13:07Z

Mento: /* General Plans */

Wed 06 June 9am PST (16:00 GMT/UTC) in #camino-mtg

==General Plans==
* Camino 1.5
** Yesterday
** Sam stayed up all night to deploy the 1.5 website; some non-critical things are still missing but we'll fill in as time goes on
** Getting killed by 1passwd (and to a lesser extent CaminoSession)
*** [http://talkback-public.mozilla.org/reports/camino/CM15/index.html Talkback]
* Camino 1.0.5
** Gecko code froze 1 May (same as 1.8[.1])
** Release set for Tues 19 Jun (post WWDC)
** We need some patches, reviews, and then landings ([[Releases:1.0.5:Links]]); everything already fixed (with a 180-compatible patch) has landed
*** Waiting on {{bug|379438}} (1.8.0 fix for password-stealing) patch to get sr
*** {{bug|175651}} (CJK font Preferences changes don't select the proper font names) now has r+/sr+; can it land with checkin love, or is a new patch needed?
** l10n: just drop the 1.5 Keychain.nib into 1.0.5, full-stop, once the patch has landed
*** a few languages missing from 1.5; ship en nib?
** relnotes in progress; need to ship to l10n soon
* Camino 1.6
** [[Development:Planning:Camino 1.6|Scoping]] (what will we fix, and who will fix them)
*** will need to re-triage Bugzilla based on the "what will we fix" results
* [[Development:Summer of Code 2007|SoC 2007]]
** Began this week
** See peeja's AppleScript proposal [[Development:Summer of Code 2007:AppleScript:Proposal|here]]; need scoping meeting on it soon-ish.
* Tinderboxen
** past turn-off date, but they're still running at MoFoCo
** ss is having fun with "lento" on MozillaTest
* Bookmark loss
** start watching for data from newer-than-1.1b builds
* Weekly Bugs and Queues update
** These are still in pretty bad shape; we have some action on our 1.0.5/1.5.1 bugs, but everything else is standing still and generating large backlogs.

==Specific bugs that need action==
=== 1.5.1/1.0.5 (priority) ===
* {{bug|175651}} - CJK (at least Chinese and Japanese) font Preferences changes not applied to any CJK Web page
** see above; possibly? ready for checkin on MOZILLA_1_8_0_BRANCH (for 1.0.5), CAMINO_1_5_BRANCH (for 1.5.1), and MOZILLA_1_8_BRANCH (for 1.6)
** in theory trunk should be OK now, but we need some testing+filing bugs against Core (at the very least, for changing default Core font prefs to Cocoa names)

=== 1.6pre (if there's time) ===
* {{bug|381846}} - Selecting a bookmark from the dock menu does not bring application to the front
** do we want the behavior proposed?

==Queries==
===Camino 1.6===
* [https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&product=Camino&target_milestone=Camino1.6&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&cmdtype=doit&order=Reuse+same+sort+as+last+time Bugs targeted at 1.6] (144) {{greyText|[+7 since last week]}} '''we need to re-triage yet based on [[Development:Planning:Camino 1.6]] (when it's finalized) 
* [https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=RESOLVED&bug_status=VERIFIED&cmdtype=doit&order=Last+Changed&field0-0-0=flagtypes.name&type0-0-0=equals&value0-0-0=camino1.6%3F Blocking ?] (0) {{greyText|[unchanged]}} 
* [https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=RESOLVED&bug_status=VERIFIED&cmdtype=doit&order=Last+Changed&field0-0-0=flagtypes.name&type0-0-0=equals&value0-0-0=camino1.6%2B Blocking +] (0) {{greyText|[unchanged]}} 
* [https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=RESOLVED&bug_status=VERIFIED&cmdtype=doit&order=Last+Changed&field0-0-0=flagtypes.name&type0-0-0=equals&value0-0-0=camino1.6- Blocking -] (0) {{greyText|[unchanged]}}
* [https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&product=Camino&target_milestone=---&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&cmdtype=doit&order=Reuse+same+sort+as+last+time Bugs without target] (395) {{greyText|[-2 since last week]}} ''we began untargeting bugs we touched that are not on the 1.6 roadmap or needing trunk changes'' 

* [https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&product=Camino&chfieldfrom=2007-05-30&chfieldto=2007-06-06&chfield=resolution&chfieldvalue=FIXED&cmdtype=doit&order=Reuse+same+sort+as+last+time Bugs fixed since last meeting] ('''10''') {{greyText|[+10 since last week]}} 

==Queues==

* [https://bugzilla.mozilla.org/request.cgi?action=queue&requester=&product=Camino&type=review&group=type Review] (6) {{greyText|[-12 since last week]}} '''4 untargeted'''
* [https://bugzilla.mozilla.org/request.cgi?action=queue&requester=&product=Camino&type=superreview&group=type Superreview] (12) {{greyText|[+6 since last week]}} (1 is our remaining 1.0.5 bug)

Status Meetings:2007-05-06:Agenda

2007-06-06T16:05:27Z

Mento: Status Meetings:2007-05-06:Agenda moved to Status Meetings:2007-06-06:Agenda

#REDIRECT [[Status Meetings:2007-06-06:Agenda]]

Status Meetings:2007-06-06:Agenda

2007-06-06T16:05:26Z

Mento: Status Meetings:2007-05-06:Agenda moved to Status Meetings:2007-06-06:Agenda

Wed 06 June 9am PST (16:00 GMT/UTC) in #camino-mtg

==General Plans==
* Camino 1.5
** Yesterday
** Sam stayed up all night to deploy the 1.5 website; some non-critical things are still missing but we'll fill in as time goes on
** Getting killed by 1passwd (and to a lesser extend CaminoSession)
*** [http://talkback-public.mozilla.org/reports/camino/CM15/index.html Talkback]
* Camino 1.0.5
** Gecko code froze 1 May (same as 1.8[.1])
** Release set for Tues 19 Jun (post WWDC)
** We need some patches, reviews, and then landings ([[Releases:1.0.5:Links]]); everything already fixed (with a 180-compatible patch) has landed
*** Waiting on {{bug|379438}} (1.8.0 fix for password-stealing) patch to get sr
*** {{bug|175651}} (CJK font Preferences changes don't select the proper font names) now has r+/sr+; can it land with checkin love, or is a new patch needed?
** l10n: just drop the 1.5 Keychain.nib into 1.0.5, full-stop, once the patch has landed
*** a few languages missing from 1.5; ship en nib?
** relnotes in progress; need to ship to l10n soon
* Camino 1.6
** [[Development:Planning:Camino 1.6|Scoping]] (what will we fix, and who will fix them)
*** will need to re-triage Bugzilla based on the "what will we fix" results
* [[Development:Summer of Code 2007|SoC 2007]]
** Began this week
** See peeja's AppleScript proposal [[Development:Summer of Code 2007:AppleScript:Proposal|here]]; need scoping meeting on it soon-ish.
* Tinderboxen
** past turn-off date, but they're still running at MoFoCo
** ss is having fun with "lento" on MozillaTest
* Bookmark loss
** start watching for data from newer-than-1.1b builds
* Weekly Bugs and Queues update
** These are still in pretty bad shape; we have some action on our 1.0.5/1.5.1 bugs, but everything else is standing still and generating large backlogs.

==Specific bugs that need action==
=== 1.5.1/1.0.5 (priority) ===
* {{bug|175651}} - CJK (at least Chinese and Japanese) font Preferences changes not applied to any CJK Web page
** see above; possibly? ready for checkin on MOZILLA_1_8_0_BRANCH (for 1.0.5), CAMINO_1_5_BRANCH (for 1.5.1), and MOZILLA_1_8_BRANCH (for 1.6)
** in theory trunk should be OK now, but we need some testing+filing bugs against Core (at the very least, for changing default Core font prefs to Cocoa names)

=== 1.6pre (if there's time) ===
* {{bug|381846}} - Selecting a bookmark from the dock menu does not bring application to the front
** do we want the behavior proposed?

==Queries==
===Camino 1.6===
* [https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&product=Camino&target_milestone=Camino1.6&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&cmdtype=doit&order=Reuse+same+sort+as+last+time Bugs targeted at 1.6] (144) {{greyText|[+7 since last week]}} '''we need to re-triage yet based on [[Development:Planning:Camino 1.6]] (when it's finalized) 
* [https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=RESOLVED&bug_status=VERIFIED&cmdtype=doit&order=Last+Changed&field0-0-0=flagtypes.name&type0-0-0=equals&value0-0-0=camino1.6%3F Blocking ?] (0) {{greyText|[unchanged]}} 
* [https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=RESOLVED&bug_status=VERIFIED&cmdtype=doit&order=Last+Changed&field0-0-0=flagtypes.name&type0-0-0=equals&value0-0-0=camino1.6%2B Blocking +] (0) {{greyText|[unchanged]}} 
* [https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=RESOLVED&bug_status=VERIFIED&cmdtype=doit&order=Last+Changed&field0-0-0=flagtypes.name&type0-0-0=equals&value0-0-0=camino1.6- Blocking -] (0) {{greyText|[unchanged]}}
* [https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&product=Camino&target_milestone=---&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&cmdtype=doit&order=Reuse+same+sort+as+last+time Bugs without target] (395) {{greyText|[-2 since last week]}} ''we began untargeting bugs we touched that are not on the 1.6 roadmap or needing trunk changes'' 

* [https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&product=Camino&chfieldfrom=2007-05-30&chfieldto=2007-06-06&chfield=resolution&chfieldvalue=FIXED&cmdtype=doit&order=Reuse+same+sort+as+last+time Bugs fixed since last meeting] ('''10''') {{greyText|[+10 since last week]}} 

==Queues==

* [https://bugzilla.mozilla.org/request.cgi?action=queue&requester=&product=Camino&type=review&group=type Review] (6) {{greyText|[-12 since last week]}} '''4 untargeted'''
* [https://bugzilla.mozilla.org/request.cgi?action=queue&requester=&product=Camino&type=superreview&group=type Superreview] (12) {{greyText|[+6 since last week]}} (1 is our remaining 1.0.5 bug)

Status Meetings:2007-05-09:Agenda

2007-05-09T16:15:17Z

Mento: /* General Plans */

Wed 09 May 9am PST (16:00 GMT/UTC) in #camino-mtg

==General Plans==
* Camino 1.5
** [http://ftp.mozilla.org/pub/mozilla.org/camino/nightly/2007-05-01-12-1.5/Camino.dmg release candy]
** waiting on:
*** Gecko to be certified OK
**** respin expected
*** website (hicks, ss, smokey)
*** l10n (status at [[Releases:1.5:l10n]])
**** slowly making progress, it seems, but most teams still not ready
*** no big bugs or ad-blocking issues
**** smokey or someone needs to check Talkback
* Camino 1.0.5
** Gecko code froze 1 May (same as 1.8[.1])
** We need some patches, reviews, and then landings ([[Releases:1.0.5:Links]])
** We'd like to release roughly concurrently with 1.5; depends on
*** l10n backporting the password stealing UI
*** patches/landings
*** relnotes
* Camino 1.6
** branching
** scoping (what will we fix, and who will fix them)
*** will need to re-triage based on the "what will we fix" results
* [[Development:Summer of Code 2007|SoC 2007]]
** begins 28 May
** need a scoping meeting
* tinderboxen
** past turn-off date, but they're still running at MoFoCo until ss gets internet(?)
** update on switching nightlies to xserve01 ?
* Bookmark loss
* Weekly Bugs and Queues update
** These will probably build up a bit as we get some early patches for post-1.5 while we finish up 1.0.5 bugs or 1.5-related work

==Specific bugs that need action==
=== 1.5.1/1.0.5 (priority) ===
* {{bug|175651}} - CJK (at least Chinese and Japanese) font Preferences changes not applied to any CJK Web page
*: murph has taken over the patch as of last week (we'd like it for 1.0.5/1.1.1); it seems OK but needs reviews.

=== 1.5+ (if there's time) ===

==Queries==
''on hiatus''

==Queues==

* [https://bugzilla.mozilla.org/request.cgi?action=queue&requester=&product=Camino&type=review&group=type Review] (10) {{greyText|[+1 since last week]}} 
* [https://bugzilla.mozilla.org/request.cgi?action=queue&requester=&product=Camino&type=superreview&group=type Superreview] (3) {{greyText|[+1 since last week]}}

Status Meetings:2007-05-02:Agenda

2007-05-02T16:09:53Z

Mento:

Wed 02 May 9am PST (16:00 GMT/UTC) in #camino-mtg

==General Plans==
* Camino 1.5
** zarro boogs found (Mon)
*** approx. 470 bugs fixed for 1.5, 25 different bug owners
** [http://ftp.mozilla.org/pub/mozilla.org/camino/nightly/2007-05-01-12-1.5/Camino.dmg release candy] built (Tues)
** waiting on:
*** Gecko to be certified OK
*** website (hicks, ss, smokey)
*** l10n (status at [[Releases:1.5:l10n]])
*** no big bugs or ad-blocking issues
** Immediate to-do:
*** beta.cb.o
*** remove "get 1.1b" from cbo
*** light promotion in reliable circles to get some testing
* Camino 1.0.5
** Gecko code froze early Tues AM (same as 1.8[.1])
** We need some patches, reviews, and then landings
** We'd like to release roughly concurrently with 1.5; depends on
*** l10n backporting the password stealing UI
*** patches/landings
*** relnotes
* Camino 1.6
** branching
** scoping (what will we fix, and who will fix them)
** timetable
* tinderboxen
** past turn-off date, but they're still running at MoFoCo until ss gets internet(?)
** update on switching nightlies to xserve01 ?
* Bookmark loss
* Weekly Bugs and Queues update
** These will probably build up a bit as we get some early patches for post-1.5 while we finish up 1.0.5 bugs or 1.5-related work

==Specific bugs that need action==
=== 1.5.1/1.0.5 (priority) ===
* {{bug|175651}} - CJK (at least Chinese and Japanese) font Preferences changes not applied to any CJK Web page
*: murph has taken over the patch as of last week (we'd like it for 1.0.5/1.1.1); it seems OK but needs reviews.
*: who can review? smfr for sr if r+ ?

=== 1.5+ (if there's time) ===
* Bugs around the tabs overflow menu ({{bug|376930}})?

==Queries==
===Camino 1.5===
* [https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&product=Camino&target_milestone=Camino1.5&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&cmdtype=doit&order=Reuse+same+sort+as+last+time Bugs targeted at 1.5] (0) {{greyText|[-4 since last week]}} 
* [https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=RESOLVED&bug_status=VERIFIED&cmdtype=doit&order=Last+Changed&field0-0-0=flagtypes.name&type0-0-0=equals&value0-0-0=camino1.5%3F Blocking ?] (0) {{greyText|[-5 since last week]}} 
* [https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=RESOLVED&bug_status=VERIFIED&cmdtype=doit&order=Last+Changed&field0-0-0=flagtypes.name&type0-0-0=equals&value0-0-0=camino1.5%2B Blocking +] (0) {{greyText|[-1 since last week]}} 
* [https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=RESOLVED&bug_status=VERIFIED&cmdtype=doit&order=Last+Changed&field0-0-0=flagtypes.name&type0-0-0=equals&value0-0-0=camino1.5- Blocking -] (14) {{greyText|[unchanged]}}
* [https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&product=Camino&target_milestone=---&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&cmdtype=doit&order=Reuse+same+sort+as+last+time Bugs without target] (309) {{greyText|[-1 since last week]}} 

* [https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&product=Camino&chfieldfrom=2007-04-25&chfieldto=2007-05-02&chfield=resolution&chfieldvalue=FIXED&cmdtype=doit&order=Reuse+same+sort+as+last+time Bugs fixed since last meeting] ('''10''') {{greyText|[+5 since last week]}} (all were 1.5-targeted or ad-blocking)

==Queues==

* [https://bugzilla.mozilla.org/request.cgi?action=queue&requester=&product=Camino&type=review&group=type Review] (9) {{greyText|[+4 since last week]}} 
* [https://bugzilla.mozilla.org/request.cgi?action=queue&requester=&product=Camino&type=superreview&group=type Superreview] (2) {{greyText|[-2 since last week]}}

Releases:Branch Tag Build Release

2007-05-01T19:58:41Z

Mento: /* Release checklist */ New prerelease version scheme

<big>How to (branch and tag and build and) release a new version of Camino</big>
 
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 [http://www.caminobrowser.org/releases/1.0.4.php Camino 1.0.4] ([http://www.mozilla.com/en-US/firefox/releases/1.5.0.10.html Gecko 1.8.0.10]). The base tag for this release was <code>FIREFOX_1_5_0_10_RELEASE</code>. This specifies the apex of the minibranch. For the 1.0.4 release, changes to that tag for Camino were made on a new <code>CAMINO_1_0_4_MINIBRANCH</code> branch, and the release tag was <code>CAMINO_1_0_4_RELEASE</code>. Camino branch and release tags follow this convention (<code>CAMINO_1_1_A2_MINIBRANCH</code>, <code>CAMINO_1_1_B_RELEASE</code>).

== 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 <code>-D</code> when checking out <code>client.mk</code>, and set <code>MOZ_CO_DATE</code> when making <code>client.mk</code>’s <code>checkout</code> 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 [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
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. <code>client.mk</code> 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 <code>client.mk</code> if that’s all that’s changing. After branching, use <code>cvs update</code> 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 (<code>mozilla</code>). 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

If using a <code>GECKOver_date_RELBRANCH</code> branch (recommended), the best practice is to only minibranch <code>client.mk</code>, and to use the Gecko release branch for any other files that need to change. For example:

cvs tag -b CAMINO_1_5_MINIBRANCH client.mk
cvs update -r CAMINO_1_5_MINIBRANCH client.mk
cvs update -r GECKO181_20070501_RELBRANCH camino # to allow files in mozilla/camino to be updated

== Fix your (my) mistakes ==

At this point, I realized that the <code>FIREFOX_1_5_0_10_RELEASE</code> tag didn’t include changes to two Camino files that had been made recently on the <code>MOZILLA_1_8_0_BRANCH</code> in anticipation of Camino 1.0.4. I realized this because the release notes were missing. I found the other file by querying [http://bonsai.mozilla.org/ 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 <code>cvs tag -B -F</code> to move the tag because <code>ad_blocking.css</code> had already been branched. <code>cvs tag -B -F</code> 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 <code>client.mk</code> apply to the release tag ==

Now it’s possible to make changes to the working copy. First, update <code>client.mk</code> so that it will pull from the release tag (soon to be created). The relevant section of <code>client.mk</code> should look something like [http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/client.mk&rev=CAMINO_1_0_4_RELEASE&mark=241-245#236 this]. In this case, <code>sed</code> 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 <code>client.mk</code>. 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 [https://bugzilla.mozilla.org/buglist.cgi?status_whiteboard_type=substring&status_whiteboard=camino-1.0.3 querying Bugzilla for bugs with text like <code>camino-1.0.3</code>] in the status whiteboard field, by [http://bonsai.mozilla.org/cvsquery.cgi?branch=CAMINO_1_0_3_MINIBRANCH&date=all checking Bonsai for changes I made to the last release minibranch], or by asking [[User:Sardisson|Smokey]] or [[User:Admin|Sam]]. Those guys remember everything. These two things come from bugs [https://bugzilla.mozilla.org/show_bug.cgi?id=325765 325765] and [https://bugzilla.mozilla.org/show_bug.cgi?id=325964 325964]. When landing things on the minibranch, don’t forget to update the status whiteboard fields of the relevant bugs with text like <code>[camino-1.0.4]</code>.

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 [http://lxr.mozilla.org/mozilla/source/camino/docs/ReleaseChecklist.txt <code>camino/docs/ReleaseChecklist.txt</code>] 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 (<code>MOZILLA_1_8_0_BRANCH</code> 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+, but this versioning scheme is deprecated. Under the new scheme, the version number should be updated the the next version expected to be released from the branch, with “pre” appended. In this example, the version would be updated to 1.0.5pre. 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 <code>client.mk</code> 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 <code>client.mk</code> by the <code>CAMINO_1_0_4_RELEASE</code> tag, then they’ll get what they expect. Change the tags in <code>client.mk</code> 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.) This is only recommended if the entire tree was forked to make a minibranch, otherwise, it's pointless. If using a Gecko release branch (recommended), you probably won't have forked the entire tree for a minibranch, so this step is safe to skip.

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 <code>$CVSROOT</code>, 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 <code>$BuildTag</code> in <code>tinder-config.pl</code> to make sure it corresponds to your chosen release tag (or branch). When building from a tag (instead of a branch), pull-by-timestamp (<code>cvs checkout -D</code>) must be turned off. It’s useful when building from branches. Its behavior is controlled by the <code>$UseTimeStamp</code> 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

Other significant variables affect the name displayed on the tinderbox status page, and the names of the directories created on the FTP server:

$BuildNameExtra = 'Cm1.0.4';
$milestone = "1.0.4";

Now, edit <code>multi-tinderbox</code>’ 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 <code>Cm1.0-M1.8.0</code> and adding a <code>Cm1.0.4</code> entry. Later, when the release is built, I’ll comment out <code>Cm1.0.4</code> and turn <code>Cm1.0-M1.8.0</code> back on. <code>multi-tinderbox</code> reloads its configuration when it receives a <code>SIGHUP</code>; 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 <code>multi-config.pl</code>.

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 <code>multi-tinderbox</code> to reload when the current build finishes:

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

When the release build begins, go to the [http://tinderbox.mozilla.org/Camino/ Camino tinderbox page], click “[http://tinderbox.mozilla.org/admintree.cgi?tree=Camino 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 your (my) mistakes|“fix-it”]] section above where I fixed <code>ad_blocking.css</code>, remembering that at this point, you’ve got both a <code>_MINIBRANCH</code> and <code>_RELEASE</code> 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 “[http://ftp.mozilla.org/pub/mozilla.org/camino/nightly/ nightly]” that tinderbox uploaded. If it seems reasonable, stage it and let people know. When possible, it’s nice to let the [http://caminol10n.mozdev.org/ 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 <code>/home/ftp/pub/camino/source/camino-1.0.4.tar.bz2</code>, and that directory has an <code>MD5SUMS</code> file as well. The multilingual release will go in
<code>/home/ftp/pub/camino/releases/Camino-1.0.4-MultiLang.dmg</code>, with a copy at <code>/home/ftp/pub/camino/releases/all/Camino-1.0.4.dmg</code>.

== Create a source release ==

We provide [http://ftp.mozilla.org/pub/mozilla.org/camino/source/ source tarballs] for major releases (not alphas, betas, or release candidates). Check out a fresh tree using anonymous CVS, so that the <code>CVS/Root</code> files are correct for people bootstrapping anonymous CVS workspaces. If the <code>.tar.bz2</code> 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|Stage it]].

== Have someone else set up Talkback reports ==

Ask Jay to set up [http://talkback-public.mozilla.org/reports/camino/ Talkback reports], at least until [http://code.google.com/p/google-breakpad/ 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 <code>Contents/MacOS/components/talkback/master.ini</code> file from <code>Camino.app</code> 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.

* Wait for mirror propagation from <code>stage.mozilla.org</code> to all of the systems handling <code>releases.mozilla.org</code>, <code>ftp.mozilla.org</code>, and other mirrors.
* Have someone on the build team update bouncer. [https://bugzilla.mozilla.org/enter_bug.cgi?product=mozilla.org&component=Build%20%26%20Release File a bug in the “mozilla.org:Build & Release” component], or e-mail [mailto:build@mozilla.org build@mozilla.org]. If you forget how to accomplish this step, ask Reed. He’s always happy to remind us.
* Someone’s got to [[Releases:Website Checklist|update the website]], the web site, or both.
* Some releases include a “release notes” URL that needs to be populated with content or a redirect. The release notes URL is defined as <code>ReleaseNotesDefault</code> in [http://lxr.mozilla.org/mozilla1.8.0/source/camino/resources/application/WebsiteDefaults.strings <code>camino/resources/application/WebsiteDefaults.strings</code>] and is updated as part of the [[#Release checklist|release checklist]]. The URL used in Camino 1.0.4 is [http://www.mozilla.org/products/camino/releases/1.0.4.html], which redirects to [http://www.caminobrowser.org/releases/1.0.4.php].

Releases:Branch Tag Build Release

2007-05-01T19:56:22Z

Mento: /* Make Tinderbox build it */ List all the variables in tinder-config that need beating

<big>How to (branch and tag and build and) release a new version of Camino</big>
 
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 [http://www.caminobrowser.org/releases/1.0.4.php Camino 1.0.4] ([http://www.mozilla.com/en-US/firefox/releases/1.5.0.10.html Gecko 1.8.0.10]). The base tag for this release was <code>FIREFOX_1_5_0_10_RELEASE</code>. This specifies the apex of the minibranch. For the 1.0.4 release, changes to that tag for Camino were made on a new <code>CAMINO_1_0_4_MINIBRANCH</code> branch, and the release tag was <code>CAMINO_1_0_4_RELEASE</code>. Camino branch and release tags follow this convention (<code>CAMINO_1_1_A2_MINIBRANCH</code>, <code>CAMINO_1_1_B_RELEASE</code>).

== 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 <code>-D</code> when checking out <code>client.mk</code>, and set <code>MOZ_CO_DATE</code> when making <code>client.mk</code>’s <code>checkout</code> 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 [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
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. <code>client.mk</code> 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 <code>client.mk</code> if that’s all that’s changing. After branching, use <code>cvs update</code> 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 (<code>mozilla</code>). 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

If using a <code>GECKOver_date_RELBRANCH</code> branch (recommended), the best practice is to only minibranch <code>client.mk</code>, and to use the Gecko release branch for any other files that need to change. For example:

cvs tag -b CAMINO_1_5_MINIBRANCH client.mk
cvs update -r CAMINO_1_5_MINIBRANCH client.mk
cvs update -r GECKO181_20070501_RELBRANCH camino # to allow files in mozilla/camino to be updated

== Fix your (my) mistakes ==

At this point, I realized that the <code>FIREFOX_1_5_0_10_RELEASE</code> tag didn’t include changes to two Camino files that had been made recently on the <code>MOZILLA_1_8_0_BRANCH</code> in anticipation of Camino 1.0.4. I realized this because the release notes were missing. I found the other file by querying [http://bonsai.mozilla.org/ 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 <code>cvs tag -B -F</code> to move the tag because <code>ad_blocking.css</code> had already been branched. <code>cvs tag -B -F</code> 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 <code>client.mk</code> apply to the release tag ==

Now it’s possible to make changes to the working copy. First, update <code>client.mk</code> so that it will pull from the release tag (soon to be created). The relevant section of <code>client.mk</code> should look something like [http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/client.mk&rev=CAMINO_1_0_4_RELEASE&mark=241-245#236 this]. In this case, <code>sed</code> 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 <code>client.mk</code>. 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 [https://bugzilla.mozilla.org/buglist.cgi?status_whiteboard_type=substring&status_whiteboard=camino-1.0.3 querying Bugzilla for bugs with text like <code>camino-1.0.3</code>] in the status whiteboard field, by [http://bonsai.mozilla.org/cvsquery.cgi?branch=CAMINO_1_0_3_MINIBRANCH&date=all checking Bonsai for changes I made to the last release minibranch], or by asking [[User:Sardisson|Smokey]] or [[User:Admin|Sam]]. Those guys remember everything. These two things come from bugs [https://bugzilla.mozilla.org/show_bug.cgi?id=325765 325765] and [https://bugzilla.mozilla.org/show_bug.cgi?id=325964 325964]. When landing things on the minibranch, don’t forget to update the status whiteboard fields of the relevant bugs with text like <code>[camino-1.0.4]</code>.

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 [http://lxr.mozilla.org/mozilla/source/camino/docs/ReleaseChecklist.txt <code>camino/docs/ReleaseChecklist.txt</code>] 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 (<code>MOZILLA_1_8_0_BRANCH</code> 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 <code>client.mk</code> 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 <code>client.mk</code> by the <code>CAMINO_1_0_4_RELEASE</code> tag, then they’ll get what they expect. Change the tags in <code>client.mk</code> 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.) This is only recommended if the entire tree was forked to make a minibranch, otherwise, it's pointless. If using a Gecko release branch (recommended), you probably won't have forked the entire tree for a minibranch, so this step is safe to skip.

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 <code>$CVSROOT</code>, 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 <code>$BuildTag</code> in <code>tinder-config.pl</code> to make sure it corresponds to your chosen release tag (or branch). When building from a tag (instead of a branch), pull-by-timestamp (<code>cvs checkout -D</code>) must be turned off. It’s useful when building from branches. Its behavior is controlled by the <code>$UseTimeStamp</code> 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

Other significant variables affect the name displayed on the tinderbox status page, and the names of the directories created on the FTP server:

$BuildNameExtra = 'Cm1.0.4';
$milestone = "1.0.4";

Now, edit <code>multi-tinderbox</code>’ 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 <code>Cm1.0-M1.8.0</code> and adding a <code>Cm1.0.4</code> entry. Later, when the release is built, I’ll comment out <code>Cm1.0.4</code> and turn <code>Cm1.0-M1.8.0</code> back on. <code>multi-tinderbox</code> reloads its configuration when it receives a <code>SIGHUP</code>; 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 <code>multi-config.pl</code>.

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 <code>multi-tinderbox</code> to reload when the current build finishes:

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

When the release build begins, go to the [http://tinderbox.mozilla.org/Camino/ Camino tinderbox page], click “[http://tinderbox.mozilla.org/admintree.cgi?tree=Camino 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 your (my) mistakes|“fix-it”]] section above where I fixed <code>ad_blocking.css</code>, remembering that at this point, you’ve got both a <code>_MINIBRANCH</code> and <code>_RELEASE</code> 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 “[http://ftp.mozilla.org/pub/mozilla.org/camino/nightly/ nightly]” that tinderbox uploaded. If it seems reasonable, stage it and let people know. When possible, it’s nice to let the [http://caminol10n.mozdev.org/ 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 <code>/home/ftp/pub/camino/source/camino-1.0.4.tar.bz2</code>, and that directory has an <code>MD5SUMS</code> file as well. The multilingual release will go in
<code>/home/ftp/pub/camino/releases/Camino-1.0.4-MultiLang.dmg</code>, with a copy at <code>/home/ftp/pub/camino/releases/all/Camino-1.0.4.dmg</code>.

== Create a source release ==

We provide [http://ftp.mozilla.org/pub/mozilla.org/camino/source/ source tarballs] for major releases (not alphas, betas, or release candidates). Check out a fresh tree using anonymous CVS, so that the <code>CVS/Root</code> files are correct for people bootstrapping anonymous CVS workspaces. If the <code>.tar.bz2</code> 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|Stage it]].

== Have someone else set up Talkback reports ==

Ask Jay to set up [http://talkback-public.mozilla.org/reports/camino/ Talkback reports], at least until [http://code.google.com/p/google-breakpad/ 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 <code>Contents/MacOS/components/talkback/master.ini</code> file from <code>Camino.app</code> 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.

* Wait for mirror propagation from <code>stage.mozilla.org</code> to all of the systems handling <code>releases.mozilla.org</code>, <code>ftp.mozilla.org</code>, and other mirrors.
* Have someone on the build team update bouncer. [https://bugzilla.mozilla.org/enter_bug.cgi?product=mozilla.org&component=Build%20%26%20Release File a bug in the “mozilla.org:Build & Release” component], or e-mail [mailto:build@mozilla.org build@mozilla.org]. If you forget how to accomplish this step, ask Reed. He’s always happy to remind us.
* Someone’s got to [[Releases:Website Checklist|update the website]], the web site, or both.
* Some releases include a “release notes” URL that needs to be populated with content or a redirect. The release notes URL is defined as <code>ReleaseNotesDefault</code> in [http://lxr.mozilla.org/mozilla1.8.0/source/camino/resources/application/WebsiteDefaults.strings <code>camino/resources/application/WebsiteDefaults.strings</code>] and is updated as part of the [[#Release checklist|release checklist]]. The URL used in Camino 1.0.4 is [http://www.mozilla.org/products/camino/releases/1.0.4.html], which redirects to [http://www.caminobrowser.org/releases/1.0.4.php].

Releases:Branch Tag Build Release

2007-05-01T19:03:34Z

Mento: /* Tag it */ More tips

<big>How to (branch and tag and build and) release a new version of Camino</big>
 
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 [http://www.caminobrowser.org/releases/1.0.4.php Camino 1.0.4] ([http://www.mozilla.com/en-US/firefox/releases/1.5.0.10.html Gecko 1.8.0.10]). The base tag for this release was <code>FIREFOX_1_5_0_10_RELEASE</code>. This specifies the apex of the minibranch. For the 1.0.4 release, changes to that tag for Camino were made on a new <code>CAMINO_1_0_4_MINIBRANCH</code> branch, and the release tag was <code>CAMINO_1_0_4_RELEASE</code>. Camino branch and release tags follow this convention (<code>CAMINO_1_1_A2_MINIBRANCH</code>, <code>CAMINO_1_1_B_RELEASE</code>).

== 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 <code>-D</code> when checking out <code>client.mk</code>, and set <code>MOZ_CO_DATE</code> when making <code>client.mk</code>’s <code>checkout</code> 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 [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
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. <code>client.mk</code> 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 <code>client.mk</code> if that’s all that’s changing. After branching, use <code>cvs update</code> 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 (<code>mozilla</code>). 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

If using a <code>GECKOver_date_RELBRANCH</code> branch (recommended), the best practice is to only minibranch <code>client.mk</code>, and to use the Gecko release branch for any other files that need to change. For example:

cvs tag -b CAMINO_1_5_MINIBRANCH client.mk
cvs update -r CAMINO_1_5_MINIBRANCH client.mk
cvs update -r GECKO181_20070501_RELBRANCH camino # to allow files in mozilla/camino to be updated

== Fix your (my) mistakes ==

At this point, I realized that the <code>FIREFOX_1_5_0_10_RELEASE</code> tag didn’t include changes to two Camino files that had been made recently on the <code>MOZILLA_1_8_0_BRANCH</code> in anticipation of Camino 1.0.4. I realized this because the release notes were missing. I found the other file by querying [http://bonsai.mozilla.org/ 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 <code>cvs tag -B -F</code> to move the tag because <code>ad_blocking.css</code> had already been branched. <code>cvs tag -B -F</code> 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 <code>client.mk</code> apply to the release tag ==

Now it’s possible to make changes to the working copy. First, update <code>client.mk</code> so that it will pull from the release tag (soon to be created). The relevant section of <code>client.mk</code> should look something like [http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/client.mk&rev=CAMINO_1_0_4_RELEASE&mark=241-245#236 this]. In this case, <code>sed</code> 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 <code>client.mk</code>. 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 [https://bugzilla.mozilla.org/buglist.cgi?status_whiteboard_type=substring&status_whiteboard=camino-1.0.3 querying Bugzilla for bugs with text like <code>camino-1.0.3</code>] in the status whiteboard field, by [http://bonsai.mozilla.org/cvsquery.cgi?branch=CAMINO_1_0_3_MINIBRANCH&date=all checking Bonsai for changes I made to the last release minibranch], or by asking [[User:Sardisson|Smokey]] or [[User:Admin|Sam]]. Those guys remember everything. These two things come from bugs [https://bugzilla.mozilla.org/show_bug.cgi?id=325765 325765] and [https://bugzilla.mozilla.org/show_bug.cgi?id=325964 325964]. When landing things on the minibranch, don’t forget to update the status whiteboard fields of the relevant bugs with text like <code>[camino-1.0.4]</code>.

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 [http://lxr.mozilla.org/mozilla/source/camino/docs/ReleaseChecklist.txt <code>camino/docs/ReleaseChecklist.txt</code>] 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 (<code>MOZILLA_1_8_0_BRANCH</code> 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 <code>client.mk</code> 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 <code>client.mk</code> by the <code>CAMINO_1_0_4_RELEASE</code> tag, then they’ll get what they expect. Change the tags in <code>client.mk</code> 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.) This is only recommended if the entire tree was forked to make a minibranch, otherwise, it's pointless. If using a Gecko release branch (recommended), you probably won't have forked the entire tree for a minibranch, so this step is safe to skip.

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 <code>$CVSROOT</code>, 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 <code>$BuildTag</code> in <code>tinder-config.pl</code> to make sure it corresponds to your chosen release tag (or branch). When building from a tag (instead of a branch), pull-by-timestamp (<code>cvs checkout -D</code>) must be turned off. It’s useful when building from branches. Its behavior is controlled by the <code>$UseTimeStamp</code> 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 <code>multi-tinderbox</code>’ 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 <code>Cm1.0-M1.8.0</code> and adding a <code>Cm1.0.4</code> entry. Later, when the release is built, I’ll comment out <code>Cm1.0.4</code> and turn <code>Cm1.0-M1.8.0</code> back on. <code>multi-tinderbox</code> reloads its configuration when it receives a <code>SIGHUP</code>; 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 <code>multi-config.pl</code>.

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 <code>multi-tinderbox</code> to reload when the current build finishes:

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

When the release build begins, go to the [http://tinderbox.mozilla.org/Camino/ Camino tinderbox page], click “[http://tinderbox.mozilla.org/admintree.cgi?tree=Camino 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 your (my) mistakes|“fix-it”]] section above where I fixed <code>ad_blocking.css</code>, remembering that at this point, you’ve got both a <code>_MINIBRANCH</code> and <code>_RELEASE</code> 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 “[http://ftp.mozilla.org/pub/mozilla.org/camino/nightly/ nightly]” that tinderbox uploaded. If it seems reasonable, stage it and let people know. When possible, it’s nice to let the [http://caminol10n.mozdev.org/ 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 <code>/home/ftp/pub/camino/source/camino-1.0.4.tar.bz2</code>, and that directory has an <code>MD5SUMS</code> file as well. The multilingual release will go in
<code>/home/ftp/pub/camino/releases/Camino-1.0.4-MultiLang.dmg</code>, with a copy at <code>/home/ftp/pub/camino/releases/all/Camino-1.0.4.dmg</code>.

== Create a source release ==

We provide [http://ftp.mozilla.org/pub/mozilla.org/camino/source/ source tarballs] for major releases (not alphas, betas, or release candidates). Check out a fresh tree using anonymous CVS, so that the <code>CVS/Root</code> files are correct for people bootstrapping anonymous CVS workspaces. If the <code>.tar.bz2</code> 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|Stage it]].

== Have someone else set up Talkback reports ==

Ask Jay to set up [http://talkback-public.mozilla.org/reports/camino/ Talkback reports], at least until [http://code.google.com/p/google-breakpad/ 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 <code>Contents/MacOS/components/talkback/master.ini</code> file from <code>Camino.app</code> 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.

* Wait for mirror propagation from <code>stage.mozilla.org</code> to all of the systems handling <code>releases.mozilla.org</code>, <code>ftp.mozilla.org</code>, and other mirrors.
* Have someone on the build team update bouncer. [https://bugzilla.mozilla.org/enter_bug.cgi?product=mozilla.org&component=Build%20%26%20Release File a bug in the “mozilla.org:Build & Release” component], or e-mail [mailto:build@mozilla.org build@mozilla.org]. If you forget how to accomplish this step, ask Reed. He’s always happy to remind us.
* Someone’s got to [[Releases:Website Checklist|update the website]], the web site, or both.
* Some releases include a “release notes” URL that needs to be populated with content or a redirect. The release notes URL is defined as <code>ReleaseNotesDefault</code> in [http://lxr.mozilla.org/mozilla1.8.0/source/camino/resources/application/WebsiteDefaults.strings <code>camino/resources/application/WebsiteDefaults.strings</code>] and is updated as part of the [[#Release checklist|release checklist]]. The URL used in Camino 1.0.4 is [http://www.mozilla.org/products/camino/releases/1.0.4.html], which redirects to [http://www.caminobrowser.org/releases/1.0.4.php].

Releases:Branch Tag Build Release

2007-05-01T19:00:31Z

Mento: /* Fork a minibranch */ More relbranch tips

<big>How to (branch and tag and build and) release a new version of Camino</big>
 
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 [http://www.caminobrowser.org/releases/1.0.4.php Camino 1.0.4] ([http://www.mozilla.com/en-US/firefox/releases/1.5.0.10.html Gecko 1.8.0.10]). The base tag for this release was <code>FIREFOX_1_5_0_10_RELEASE</code>. This specifies the apex of the minibranch. For the 1.0.4 release, changes to that tag for Camino were made on a new <code>CAMINO_1_0_4_MINIBRANCH</code> branch, and the release tag was <code>CAMINO_1_0_4_RELEASE</code>. Camino branch and release tags follow this convention (<code>CAMINO_1_1_A2_MINIBRANCH</code>, <code>CAMINO_1_1_B_RELEASE</code>).

== 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 <code>-D</code> when checking out <code>client.mk</code>, and set <code>MOZ_CO_DATE</code> when making <code>client.mk</code>’s <code>checkout</code> 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 [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
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. <code>client.mk</code> 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 <code>client.mk</code> if that’s all that’s changing. After branching, use <code>cvs update</code> 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 (<code>mozilla</code>). 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

If using a <code>GECKOver_date_RELBRANCH</code> branch (recommended), the best practice is to only minibranch <code>client.mk</code>, and to use the Gecko release branch for any other files that need to change. For example:

cvs tag -b CAMINO_1_5_MINIBRANCH client.mk
cvs update -r CAMINO_1_5_MINIBRANCH client.mk
cvs update -r GECKO181_20070501_RELBRANCH camino # to allow files in mozilla/camino to be updated

== Fix your (my) mistakes ==

At this point, I realized that the <code>FIREFOX_1_5_0_10_RELEASE</code> tag didn’t include changes to two Camino files that had been made recently on the <code>MOZILLA_1_8_0_BRANCH</code> in anticipation of Camino 1.0.4. I realized this because the release notes were missing. I found the other file by querying [http://bonsai.mozilla.org/ 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 <code>cvs tag -B -F</code> to move the tag because <code>ad_blocking.css</code> had already been branched. <code>cvs tag -B -F</code> 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 <code>client.mk</code> apply to the release tag ==

Now it’s possible to make changes to the working copy. First, update <code>client.mk</code> so that it will pull from the release tag (soon to be created). The relevant section of <code>client.mk</code> should look something like [http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/client.mk&rev=CAMINO_1_0_4_RELEASE&mark=241-245#236 this]. In this case, <code>sed</code> 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 <code>client.mk</code>. 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 [https://bugzilla.mozilla.org/buglist.cgi?status_whiteboard_type=substring&status_whiteboard=camino-1.0.3 querying Bugzilla for bugs with text like <code>camino-1.0.3</code>] in the status whiteboard field, by [http://bonsai.mozilla.org/cvsquery.cgi?branch=CAMINO_1_0_3_MINIBRANCH&date=all checking Bonsai for changes I made to the last release minibranch], or by asking [[User:Sardisson|Smokey]] or [[User:Admin|Sam]]. Those guys remember everything. These two things come from bugs [https://bugzilla.mozilla.org/show_bug.cgi?id=325765 325765] and [https://bugzilla.mozilla.org/show_bug.cgi?id=325964 325964]. When landing things on the minibranch, don’t forget to update the status whiteboard fields of the relevant bugs with text like <code>[camino-1.0.4]</code>.

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 [http://lxr.mozilla.org/mozilla/source/camino/docs/ReleaseChecklist.txt <code>camino/docs/ReleaseChecklist.txt</code>] 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 (<code>MOZILLA_1_8_0_BRANCH</code> 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 <code>client.mk</code> 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 <code>client.mk</code> by the <code>CAMINO_1_0_4_RELEASE</code> tag, then they’ll get what they expect. Change the tags in <code>client.mk</code> 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 <code>$CVSROOT</code>, 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 <code>$BuildTag</code> in <code>tinder-config.pl</code> to make sure it corresponds to your chosen release tag (or branch). When building from a tag (instead of a branch), pull-by-timestamp (<code>cvs checkout -D</code>) must be turned off. It’s useful when building from branches. Its behavior is controlled by the <code>$UseTimeStamp</code> 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 <code>multi-tinderbox</code>’ 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 <code>Cm1.0-M1.8.0</code> and adding a <code>Cm1.0.4</code> entry. Later, when the release is built, I’ll comment out <code>Cm1.0.4</code> and turn <code>Cm1.0-M1.8.0</code> back on. <code>multi-tinderbox</code> reloads its configuration when it receives a <code>SIGHUP</code>; 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 <code>multi-config.pl</code>.

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 <code>multi-tinderbox</code> to reload when the current build finishes:

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

When the release build begins, go to the [http://tinderbox.mozilla.org/Camino/ Camino tinderbox page], click “[http://tinderbox.mozilla.org/admintree.cgi?tree=Camino 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 your (my) mistakes|“fix-it”]] section above where I fixed <code>ad_blocking.css</code>, remembering that at this point, you’ve got both a <code>_MINIBRANCH</code> and <code>_RELEASE</code> 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 “[http://ftp.mozilla.org/pub/mozilla.org/camino/nightly/ nightly]” that tinderbox uploaded. If it seems reasonable, stage it and let people know. When possible, it’s nice to let the [http://caminol10n.mozdev.org/ 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 <code>/home/ftp/pub/camino/source/camino-1.0.4.tar.bz2</code>, and that directory has an <code>MD5SUMS</code> file as well. The multilingual release will go in
<code>/home/ftp/pub/camino/releases/Camino-1.0.4-MultiLang.dmg</code>, with a copy at <code>/home/ftp/pub/camino/releases/all/Camino-1.0.4.dmg</code>.

== Create a source release ==

We provide [http://ftp.mozilla.org/pub/mozilla.org/camino/source/ source tarballs] for major releases (not alphas, betas, or release candidates). Check out a fresh tree using anonymous CVS, so that the <code>CVS/Root</code> files are correct for people bootstrapping anonymous CVS workspaces. If the <code>.tar.bz2</code> 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|Stage it]].

== Have someone else set up Talkback reports ==

Ask Jay to set up [http://talkback-public.mozilla.org/reports/camino/ Talkback reports], at least until [http://code.google.com/p/google-breakpad/ 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 <code>Contents/MacOS/components/talkback/master.ini</code> file from <code>Camino.app</code> 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.

* Wait for mirror propagation from <code>stage.mozilla.org</code> to all of the systems handling <code>releases.mozilla.org</code>, <code>ftp.mozilla.org</code>, and other mirrors.
* Have someone on the build team update bouncer. [https://bugzilla.mozilla.org/enter_bug.cgi?product=mozilla.org&component=Build%20%26%20Release File a bug in the “mozilla.org:Build & Release” component], or e-mail [mailto:build@mozilla.org build@mozilla.org]. If you forget how to accomplish this step, ask Reed. He’s always happy to remind us.
* Someone’s got to [[Releases:Website Checklist|update the website]], the web site, or both.
* Some releases include a “release notes” URL that needs to be populated with content or a redirect. The release notes URL is defined as <code>ReleaseNotesDefault</code> in [http://lxr.mozilla.org/mozilla1.8.0/source/camino/resources/application/WebsiteDefaults.strings <code>camino/resources/application/WebsiteDefaults.strings</code>] and is updated as part of the [[#Release checklist|release checklist]]. The URL used in Camino 1.0.4 is [http://www.mozilla.org/products/camino/releases/1.0.4.html], which redirects to [http://www.caminobrowser.org/releases/1.0.4.php].

Releases:Branch Tag Build Release

2007-05-01T18:45:18Z

Mento: /* Check out the source */ Identify build team's new branch scheme

<big>How to (branch and tag and build and) release a new version of Camino</big>
 
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 [http://www.caminobrowser.org/releases/1.0.4.php Camino 1.0.4] ([http://www.mozilla.com/en-US/firefox/releases/1.5.0.10.html Gecko 1.8.0.10]). The base tag for this release was <code>FIREFOX_1_5_0_10_RELEASE</code>. This specifies the apex of the minibranch. For the 1.0.4 release, changes to that tag for Camino were made on a new <code>CAMINO_1_0_4_MINIBRANCH</code> branch, and the release tag was <code>CAMINO_1_0_4_RELEASE</code>. Camino branch and release tags follow this convention (<code>CAMINO_1_1_A2_MINIBRANCH</code>, <code>CAMINO_1_1_B_RELEASE</code>).

== 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 <code>-D</code> when checking out <code>client.mk</code>, and set <code>MOZ_CO_DATE</code> when making <code>client.mk</code>’s <code>checkout</code> 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 [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
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. <code>client.mk</code> 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 <code>client.mk</code> if that’s all that’s changing. After branching, use <code>cvs update</code> 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 (<code>mozilla</code>). 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 <code>FIREFOX_1_5_0_10_RELEASE</code> tag didn’t include changes to two Camino files that had been made recently on the <code>MOZILLA_1_8_0_BRANCH</code> in anticipation of Camino 1.0.4. I realized this because the release notes were missing. I found the other file by querying [http://bonsai.mozilla.org/ 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 <code>cvs tag -B -F</code> to move the tag because <code>ad_blocking.css</code> had already been branched. <code>cvs tag -B -F</code> 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 <code>client.mk</code> apply to the release tag ==

Now it’s possible to make changes to the working copy. First, update <code>client.mk</code> so that it will pull from the release tag (soon to be created). The relevant section of <code>client.mk</code> should look something like [http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/client.mk&rev=CAMINO_1_0_4_RELEASE&mark=241-245#236 this]. In this case, <code>sed</code> 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 <code>client.mk</code>. 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 [https://bugzilla.mozilla.org/buglist.cgi?status_whiteboard_type=substring&status_whiteboard=camino-1.0.3 querying Bugzilla for bugs with text like <code>camino-1.0.3</code>] in the status whiteboard field, by [http://bonsai.mozilla.org/cvsquery.cgi?branch=CAMINO_1_0_3_MINIBRANCH&date=all checking Bonsai for changes I made to the last release minibranch], or by asking [[User:Sardisson|Smokey]] or [[User:Admin|Sam]]. Those guys remember everything. These two things come from bugs [https://bugzilla.mozilla.org/show_bug.cgi?id=325765 325765] and [https://bugzilla.mozilla.org/show_bug.cgi?id=325964 325964]. When landing things on the minibranch, don’t forget to update the status whiteboard fields of the relevant bugs with text like <code>[camino-1.0.4]</code>.

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 [http://lxr.mozilla.org/mozilla/source/camino/docs/ReleaseChecklist.txt <code>camino/docs/ReleaseChecklist.txt</code>] 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 (<code>MOZILLA_1_8_0_BRANCH</code> 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 <code>client.mk</code> 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 <code>client.mk</code> by the <code>CAMINO_1_0_4_RELEASE</code> tag, then they’ll get what they expect. Change the tags in <code>client.mk</code> 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 <code>$CVSROOT</code>, 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 <code>$BuildTag</code> in <code>tinder-config.pl</code> to make sure it corresponds to your chosen release tag (or branch). When building from a tag (instead of a branch), pull-by-timestamp (<code>cvs checkout -D</code>) must be turned off. It’s useful when building from branches. Its behavior is controlled by the <code>$UseTimeStamp</code> 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 <code>multi-tinderbox</code>’ 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 <code>Cm1.0-M1.8.0</code> and adding a <code>Cm1.0.4</code> entry. Later, when the release is built, I’ll comment out <code>Cm1.0.4</code> and turn <code>Cm1.0-M1.8.0</code> back on. <code>multi-tinderbox</code> reloads its configuration when it receives a <code>SIGHUP</code>; 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 <code>multi-config.pl</code>.

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 <code>multi-tinderbox</code> to reload when the current build finishes:

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

When the release build begins, go to the [http://tinderbox.mozilla.org/Camino/ Camino tinderbox page], click “[http://tinderbox.mozilla.org/admintree.cgi?tree=Camino 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 your (my) mistakes|“fix-it”]] section above where I fixed <code>ad_blocking.css</code>, remembering that at this point, you’ve got both a <code>_MINIBRANCH</code> and <code>_RELEASE</code> 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 “[http://ftp.mozilla.org/pub/mozilla.org/camino/nightly/ nightly]” that tinderbox uploaded. If it seems reasonable, stage it and let people know. When possible, it’s nice to let the [http://caminol10n.mozdev.org/ 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 <code>/home/ftp/pub/camino/source/camino-1.0.4.tar.bz2</code>, and that directory has an <code>MD5SUMS</code> file as well. The multilingual release will go in
<code>/home/ftp/pub/camino/releases/Camino-1.0.4-MultiLang.dmg</code>, with a copy at <code>/home/ftp/pub/camino/releases/all/Camino-1.0.4.dmg</code>.

== Create a source release ==

We provide [http://ftp.mozilla.org/pub/mozilla.org/camino/source/ source tarballs] for major releases (not alphas, betas, or release candidates). Check out a fresh tree using anonymous CVS, so that the <code>CVS/Root</code> files are correct for people bootstrapping anonymous CVS workspaces. If the <code>.tar.bz2</code> 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|Stage it]].

== Have someone else set up Talkback reports ==

Ask Jay to set up [http://talkback-public.mozilla.org/reports/camino/ Talkback reports], at least until [http://code.google.com/p/google-breakpad/ 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 <code>Contents/MacOS/components/talkback/master.ini</code> file from <code>Camino.app</code> 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.

* Wait for mirror propagation from <code>stage.mozilla.org</code> to all of the systems handling <code>releases.mozilla.org</code>, <code>ftp.mozilla.org</code>, and other mirrors.
* Have someone on the build team update bouncer. [https://bugzilla.mozilla.org/enter_bug.cgi?product=mozilla.org&component=Build%20%26%20Release File a bug in the “mozilla.org:Build & Release” component], or e-mail [mailto:build@mozilla.org build@mozilla.org]. If you forget how to accomplish this step, ask Reed. He’s always happy to remind us.
* Someone’s got to [[Releases:Website Checklist|update the website]], the web site, or both.
* Some releases include a “release notes” URL that needs to be populated with content or a redirect. The release notes URL is defined as <code>ReleaseNotesDefault</code> in [http://lxr.mozilla.org/mozilla1.8.0/source/camino/resources/application/WebsiteDefaults.strings <code>camino/resources/application/WebsiteDefaults.strings</code>] and is updated as part of the [[#Release checklist|release checklist]]. The URL used in Camino 1.0.4 is [http://www.mozilla.org/products/camino/releases/1.0.4.html], which redirects to [http://www.caminobrowser.org/releases/1.0.4.php].

Releases:1.5:Notes

2007-04-30T18:49:59Z

Mento:

{{greyText|Apparently, the website used [[Releases:1.5:Notes:Web]] format for the final 1.0 notes, while the Release Notes RTF used a different format :p }}

=About Camino® 1.5=
After over a year of hard work by devoted volunteers, the Camino Project is proud to give you Camino 1.5. This latest version fixes hundreds of bugs and implements many new features, providing all users with an improved browsing experience.

Camino 1.5 brings you a heavily updated version of the only native Mac OS X browser using Mozilla’s Gecko rendering engine. This release displays web pages with Gecko 1.8.1, the same rendering engine used by the popular Firefox 2 web browser. Gecko 1.8.1 includes thousands of bug fixes over the version used by Camino 1.0, providing users even better web page compatibility.

The features listed below are just some of the many changes in Camino 1.5.

Due to changes in the feature set, Camino 1.5 no longer supports Mac OS X 10.2. We advise users still running Mac OS X 10.2 to download [http://www.caminobrowser.org/download/releases/1.0.4/ Camino 1.0.4] ([http://www.caminobrowser.org/releases/1.0.4.php release notes]).

=Features in Camino 1.5=

The following are the major changes and improvements made since the Camino 1.0 release. A full list is available on our [http://www.caminobrowser.org/releases/1.5-complete.php website].

* '''Spelling'''
** Spell-checking using the Mac OS X spelling dictionaries is now enabled in web page text fields.
* '''Feed detection'''
** When a web page offers an Atom or RSS feed, Camino will display an icon in the location bar, and clicking the icon will pass the feed to the system’s default feed reading application.
* '''Session restore'''
** Camino can remember which pages were open when quitting and restore them the next time it opens.
** After a browsing session has terminated unexpectedly, Camino will offer to restore the pages which were open previously.
* '''Improved tabbed browsing'''
** Single-window mode: There is a new option to force links that would open new windows to open in new tabs instead.
** Tab jumpback: Camino now supports returning to the original tab after viewing a page in a new tab.
* '''Keychain compatibility'''
** Camino can now share Keychain entries with Safari.
** Keychain entries saved by Camino are now saved in a way that allows other applications to read them.
* '''Pop-up blocking'''
** The pop-up blocking notification is now more visible.
** The new pop-up notification offers more powerful controls for managing pop-ups.
* '''Enhanced plug-in control'''
** Camino 1.5 includes the ability to disable all plug-ins.
** Flashblock: The new “Block Flash animations” option prevents Flash from starting until the user clicks Play.
* '''Window zooming'''
** The Zoom command now resizes the window to fit the current page’s content instead of making the window full-screen.
* '''Downloading'''
** A new optional toolbar icon in the Downloads window allows users to move downloaded files to the Trash.
** Items in the Downloads window can now be automatically removed upon completion or when quitting Camino.
* '''Searching'''
** The search field in the toolbar is now resizable.
** The context menu for selected text in web pages now includes a “Search” item.
* '''Cookie management'''
** Camino now includes an option to accept cookies only for the current session.
* '''User interface polish'''
** Camino 1.5 includes a major reorganization of menus and keyboard shortcuts. The preference panes have been redesigned.
* '''Web content'''
** Camino now uses version 1.8.1 of Mozilla’s Gecko rendering engine, which contains thousands of bug fixes and support for new technologies like JavaScript 1.7.

=Known Issues=
For information about other issues or problems, please visit our [http://www.caminobrowser.org/help/ Help page].

* Some users have experienced a situation where pages would appear not to load after clicking on a link. In this case, resizing the browser window may allow the page to display properly.

* Microsoft’s Windows Media Player (WMP) plugin causes major rendering issues in Camino. Since Microsoft has discontinued WMP on Mac OS X, Camino no longer supports the use of the WMP plugin; instead, all users should download the free Flip4Mac (F4M) plugin, version 2.1 or higher, from http://www.flip4mac.com/. Version 2.1 causes pages containing WMP content to become white when scrolled in Camino; there is currently no ETA for a fixed version of the F4M plugin.

* Camino erroneously claims that the default Japanese and Traditional Chinese fonts are “missing” when they are actually installed; this is due to a mismatch between Carbon and Cocoa font names. Changing these fonts using the Camino user interface will result in incorrect fonts being chosen and will cause some characters to fail to display. Users should either keep the default fonts or change the font preferences in the preferences file manually, ensuring the Carbon versions of the font names are used.

Development:Planning:dmg License Localization

2007-04-24T19:33:16Z

Mento: /* Tasks */

{{bug|363010}} tracks the initial work to add localized versions of the MoFo EULA to our .dmg. [[User:smorgan|smorgan]] has taken on the thankless task of preparing the initial version. Below is the list of outstanding tasks.

==Tasks==

* Determine appropriate smart quotes for Spanish
* Determine appropriate smart quotes for CJK languages, if relevant:
** Japanese
** Simplified Chinese
** Traditional Chinese
** Korean

* Determine appropriate smart elipsis for CJK languages, if relevant:
** Japanese
** Simplified Chinese
** Traditional Chinese
** Korean

* Translations into all 8 languages of the phrase
*: You are about to install Camino. Please read the license agreement. If you agree to its terms and accept, click “Accept” to access the software. Otherwise, click “Decline” to cancel.
*:* '''''N.B.''' Quotes here are smart quotes''
*:* '''''N.B.''' mento sez: the original Apple samples used “Accept” and “Reject,” for the buttons, which I changed. I'm pretty sure I rephrased the “You are about…” text as well.
** French
** German
** Italian
** Spanish
** Japanese
** Simplified Chinese
** Traditional Chinese
** Korean

* Translations into all 8 languages of the phrase
*: FOR TRANSLATIONS OF THIS LICENSE INTO SELECTED LANGUAGES, PLEASE VISIT WWW.MOZILLA.ORG/LICENSING.
** French
** German
** Italian
** Spanish
** Japanese
** Simplified Chinese
** Traditional Chinese
** Korean

* Informal “sign-off” by caminol10n teams for the 8 languages that the existing non-license text (above the “Camino End-User Software License Agreement” bold line) seems correct and relevant.
** French
** German
** Italian
** Spanish
** Japanese
** Simplified Chinese
** Traditional Chinese
** Korean

* Informal “sign-off” by caminol10n teams for the 8 languages that the existing button labels are correct (they should be, since they came from Apple).
** French
** German
** Italian
** Spanish
** Japanese
** Simplified Chinese
** Traditional Chinese
** Korean

Releases:Branch Tag Build Release

2007-03-01T21:18:42Z

Mento: /* Have someone else set up Talkback reports */

<big>How to (branch and tag and build and) release a new version of Camino</big>
 
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 [http://www.caminobrowser.org/releases/1.0.4.php Camino 1.0.4] ([http://www.mozilla.com/en-US/firefox/releases/1.5.0.10.html Gecko 1.8.0.10]). The base tag for this release was <code>FIREFOX_1_5_0_10_RELEASE</code>. This specifies the apex of the minibranch. For the 1.0.4 release, changes to that tag for Camino were made on a new <code>CAMINO_1_0_4_MINIBRANCH</code> branch, and the release tag was <code>CAMINO_1_0_4_RELEASE</code>. Camino branch and release tags follow this convention (<code>CAMINO_1_1_A2_MINIBRANCH</code>, <code>CAMINO_1_1_B_RELEASE</code>).

== 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 <code>-D</code> when checking out <code>client.mk</code>, and set <code>MOZ_CO_DATE</code> when making <code>client.mk</code>’s <code>checkout</code> 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 [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.

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. <code>client.mk</code> 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 <code>client.mk</code> if that’s all that’s changing. After branching, use <code>cvs update</code> 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 (<code>mozilla</code>). 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 <code>FIREFOX_1_5_0_10_RELEASE</code> tag didn’t include changes to two Camino files that had been made recently on the <code>MOZILLA_1_8_0_BRANCH</code> in anticipation of Camino 1.0.4. I realized this because the release notes were missing. I found the other file by querying [http://bonsai.mozilla.org/ 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 <code>cvs tag -B -F</code> to move the tag because <code>ad_blocking.css</code> had already been branched. <code>cvs tag -B -F</code> 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 <code>client.mk</code> apply to the release tag ==

Now it’s possible to make changes to the working copy. First, update <code>client.mk</code> so that it will pull from the release tag (soon to be created). The relevant section of <code>client.mk</code> should look something like [http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/client.mk&rev=CAMINO_1_0_4_RELEASE&mark=241-245#236 this]. In this case, <code>sed</code> 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 <code>client.mk</code>. 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 [https://bugzilla.mozilla.org/buglist.cgi?status_whiteboard_type=substring&status_whiteboard=camino-1.0.3 querying Bugzilla for bugs with text like <code>camino-1.0.3</code>] in the status whiteboard field, by [http://bonsai.mozilla.org/cvsquery.cgi?branch=CAMINO_1_0_3_MINIBRANCH&date=all checking Bonsai for changes I made to the last release minibranch], or by asking [[User:Sardisson|Smokey]] or [[User:Admin|Sam]]. Those guys remember everything. These two things come from bugs [https://bugzilla.mozilla.org/show_bug.cgi?id=325765 325765] and [https://bugzilla.mozilla.org/show_bug.cgi?id=325964 325964]. When landing things on the minibranch, don’t forget to update the status whiteboard fields of the relevant bugs with text like <code>[camino-1.0.4]</code>.

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 [http://lxr.mozilla.org/mozilla/source/camino/docs/ReleaseChecklist.txt <code>camino/docs/ReleaseChecklist.txt</code>] 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 (<code>MOZILLA_1_8_0_BRANCH</code> 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 <code>client.mk</code> 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 <code>client.mk</code> by the <code>CAMINO_1_0_4_RELEASE</code> tag, then they’ll get what they expect. Change the tags in <code>client.mk</code> 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 <code>$CVSROOT</code>, 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 <code>$BuildTag</code> in <code>tinder-config.pl</code> to make sure it corresponds to your chosen release tag (or branch). When building from a tag (instead of a branch), pull-by-timestamp (<code>cvs checkout -D</code>) must be turned off. It’s useful when building from branches. Its behavior is controlled by the <code>$UseTimeStamp</code> 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 <code>multi-tinderbox</code>’ 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 <code>Cm1.0-M1.8.0</code> and adding a <code>Cm1.0.4</code> entry. Later, when the release is built, I’ll comment out <code>Cm1.0.4</code> and turn <code>Cm1.0-M1.8.0</code> back on. <code>multi-tinderbox</code> reloads its configuration when it receives a <code>SIGHUP</code>; 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 <code>multi-config.pl</code>.

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 <code>multi-tinderbox</code> to reload when the current build finishes:

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

When the release build begins, go to the [http://tinderbox.mozilla.org/Camino/ Camino tinderbox page], click “[http://tinderbox.mozilla.org/admintree.cgi?tree=Camino 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 your (my) mistakes|“fix-it”]] section above where I fixed <code>ad_blocking.css</code>, remembering that at this point, you’ve got both a <code>_MINIBRANCH</code> and <code>_RELEASE</code> 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 “[http://ftp.mozilla.org/pub/mozilla.org/camino/nightly/ nightly]” that tinderbox uploaded. If it seems reasonable, stage it and let people know. When possible, it’s nice to let the [http://caminol10n.mozdev.org/ 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 <code>/home/ftp/pub/camino/source/camino-1.0.4.tar.bz2</code>, and that directory has an <code>MD5SUMS</code> file as well. The multilingual release will go in
<code>/home/ftp/pub/camino/releases/Camino-1.0.4-MultiLang.dmg</code>, with a copy at <code>/home/ftp/pub/camino/releases/all/Camino-1.0.4.dmg</code>.

== Create a source release ==

We provide [http://ftp.mozilla.org/pub/mozilla.org/camino/source/ source tarballs] for major releases (not alphas, betas, or release candidates). Check out a fresh tree using anonymous CVS, so that the <code>CVS/Root</code> files are correct for people bootstrapping anonymous CVS workspaces. If the <code>.tar.bz2</code> 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|Stage it]].

== Have someone else set up Talkback reports ==

Ask Jay to set up [http://talkback-public.mozilla.org/reports/camino/ Talkback reports], at least until [http://code.google.com/p/google-breakpad/ 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 <code>Contents/MacOS/components/talkback/master.ini</code> file from <code>Camino.app</code> 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.

* Wait for mirror propagation from <code>stage.mozilla.org</code> to all of the systems handling <code>releases.mozilla.org</code>, <code>ftp.mozilla.org</code>, and other mirrors.
* Have someone on the build team update bouncer. [https://bugzilla.mozilla.org/enter_bug.cgi?product=mozilla.org&component=Build%20%26%20Release File a bug in the “mozilla.org:Build & Release” component], or e-mail [mailto:build@mozilla.org build@mozilla.org]. If you forget how to accomplish this step, ask Reed. He’s always happy to remind us.
* Someone’s got to [[Releases:Website Checklist|update the website]], the web site, or both.
* Some releases include a “release notes” URL that needs to be populated with content or a redirect. The release notes URL is defined as <code>ReleaseNotesDefault</code> in [http://lxr.mozilla.org/mozilla1.8.0/source/camino/resources/application/WebsiteDefaults.strings <code>camino/resources/application/WebsiteDefaults.strings</code>] and is updated as part of the [[#Release checklist|release checklist]]. The URL used in Camino 1.0.4 is [http://www.mozilla.org/products/camino/releases/1.0.4.html], which redirects to [http://www.caminobrowser.org/releases/1.0.4.php].

Releases:Branch Tag Build Release

2007-03-01T21:16:04Z

Mento: /* Fork a minibranch */ Clarify that the tag isn't moving on the server when you run |cvs update|

<big>How to (branch and tag and build and) release a new version of Camino</big>
 
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 [http://www.caminobrowser.org/releases/1.0.4.php Camino 1.0.4] ([http://www.mozilla.com/en-US/firefox/releases/1.5.0.10.html Gecko 1.8.0.10]). The base tag for this release was <code>FIREFOX_1_5_0_10_RELEASE</code>. This specifies the apex of the minibranch. For the 1.0.4 release, changes to that tag for Camino were made on a new <code>CAMINO_1_0_4_MINIBRANCH</code> branch, and the release tag was <code>CAMINO_1_0_4_RELEASE</code>. Camino branch and release tags follow this convention (<code>CAMINO_1_1_A2_MINIBRANCH</code>, <code>CAMINO_1_1_B_RELEASE</code>).

== 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 <code>-D</code> when checking out <code>client.mk</code>, and set <code>MOZ_CO_DATE</code> when making <code>client.mk</code>’s <code>checkout</code> 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 [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.

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. <code>client.mk</code> 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 <code>client.mk</code> if that’s all that’s changing. After branching, use <code>cvs update</code> 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 (<code>mozilla</code>). 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 <code>FIREFOX_1_5_0_10_RELEASE</code> tag didn’t include changes to two Camino files that had been made recently on the <code>MOZILLA_1_8_0_BRANCH</code> in anticipation of Camino 1.0.4. I realized this because the release notes were missing. I found the other file by querying [http://bonsai.mozilla.org/ 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 <code>cvs tag -B -F</code> to move the tag because <code>ad_blocking.css</code> had already been branched. <code>cvs tag -B -F</code> 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 <code>client.mk</code> apply to the release tag ==

Now it’s possible to make changes to the working copy. First, update <code>client.mk</code> so that it will pull from the release tag (soon to be created). The relevant section of <code>client.mk</code> should look something like [http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/client.mk&rev=CAMINO_1_0_4_RELEASE&mark=241-245#236 this]. In this case, <code>sed</code> 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 <code>client.mk</code>. 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 [https://bugzilla.mozilla.org/buglist.cgi?status_whiteboard_type=substring&status_whiteboard=camino-1.0.3 querying Bugzilla for bugs with text like <code>camino-1.0.3</code>] in the status whiteboard field, by [http://bonsai.mozilla.org/cvsquery.cgi?branch=CAMINO_1_0_3_MINIBRANCH&date=all checking Bonsai for changes I made to the last release minibranch], or by asking [[User:Sardisson|Smokey]] or [[User:Admin|Sam]]. Those guys remember everything. These two things come from bugs [https://bugzilla.mozilla.org/show_bug.cgi?id=325765 325765] and [https://bugzilla.mozilla.org/show_bug.cgi?id=325964 325964]. When landing things on the minibranch, don’t forget to update the status whiteboard fields of the relevant bugs with text like <code>[camino-1.0.4]</code>.

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 [http://lxr.mozilla.org/mozilla/source/camino/docs/ReleaseChecklist.txt <code>camino/docs/ReleaseChecklist.txt</code>] 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 (<code>MOZILLA_1_8_0_BRANCH</code> 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 <code>client.mk</code> 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 <code>client.mk</code> by the <code>CAMINO_1_0_4_RELEASE</code> tag, then they’ll get what they expect. Change the tags in <code>client.mk</code> 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 <code>$CVSROOT</code>, 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 <code>$BuildTag</code> in <code>tinder-config.pl</code> to make sure it corresponds to your chosen release tag (or branch). When building from a tag (instead of a branch), pull-by-timestamp (<code>cvs checkout -D</code>) must be turned off. It’s useful when building from branches. Its behavior is controlled by the <code>$UseTimeStamp</code> 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 <code>multi-tinderbox</code>’ 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 <code>Cm1.0-M1.8.0</code> and adding a <code>Cm1.0.4</code> entry. Later, when the release is built, I’ll comment out <code>Cm1.0.4</code> and turn <code>Cm1.0-M1.8.0</code> back on. <code>multi-tinderbox</code> reloads its configuration when it receives a <code>SIGHUP</code>; 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 <code>multi-config.pl</code>.

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 <code>multi-tinderbox</code> to reload when the current build finishes:

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

When the release build begins, go to the [http://tinderbox.mozilla.org/Camino/ Camino tinderbox page], click “[http://tinderbox.mozilla.org/admintree.cgi?tree=Camino 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 your (my) mistakes|“fix-it”]] section above where I fixed <code>ad_blocking.css</code>, remembering that at this point, you’ve got both a <code>_MINIBRANCH</code> and <code>_RELEASE</code> 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 “[http://ftp.mozilla.org/pub/mozilla.org/camino/nightly/ nightly]” that tinderbox uploaded. If it seems reasonable, stage it and let people know. When possible, it’s nice to let the [http://caminol10n.mozdev.org/ 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 <code>/home/ftp/pub/camino/source/camino-1.0.4.tar.bz2</code>, and that directory has an <code>MD5SUMS</code> file as well. The multilingual release will go in
<code>/home/ftp/pub/camino/releases/Camino-1.0.4-MultiLang.dmg</code>, with a copy at <code>/home/ftp/pub/camino/releases/all/Camino-1.0.4.dmg</code>.

== Create a source release ==

We provide [http://ftp.mozilla.org/pub/mozilla.org/camino/source/ source tarballs] for major releases (not alphas, betas, or release candidates). Check out a fresh tree using anonymous CVS, so that the <code>CVS/Root</code> files are correct for people bootstrapping anonymous CVS workspaces. If the <code>.tar.bz2</code> 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|Stage it]].

== Have someone else set up Talkback reports ==

Ask Jay to set up [http://talkback-public.mozilla.org/reports/camino/ Talkback reports], at least until [http://code.google.com/p/google-breakpad/ Breakpad] is ready. Send him an e-mail with the relevant build information, like:

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

You can find this information from the <code>Contents/MacOS/components/talkback/master.ini</code> file from <code>Camino.app</code> 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.

* Wait for mirror propagation from <code>stage.mozilla.org</code> to all of the systems handling <code>releases.mozilla.org</code>, <code>ftp.mozilla.org</code>, and other mirrors.
* Have someone on the build team update bouncer. [https://bugzilla.mozilla.org/enter_bug.cgi?product=mozilla.org&component=Build%20%26%20Release File a bug in the “mozilla.org:Build & Release” component], or e-mail [mailto:build@mozilla.org build@mozilla.org]. If you forget how to accomplish this step, ask Reed. He’s always happy to remind us.
* Someone’s got to [[Releases:Website Checklist|update the website]], the web site, or both.
* Some releases include a “release notes” URL that needs to be populated with content or a redirect. The release notes URL is defined as <code>ReleaseNotesDefault</code> in [http://lxr.mozilla.org/mozilla1.8.0/source/camino/resources/application/WebsiteDefaults.strings <code>camino/resources/application/WebsiteDefaults.strings</code>] and is updated as part of the [[#Release checklist|release checklist]]. The URL used in Camino 1.0.4 is [http://www.mozilla.org/products/camino/releases/1.0.4.html], which redirects to [http://www.caminobrowser.org/releases/1.0.4.php].

Releases:Branch Tag Build Release

2007-03-01T21:05:40Z

Mento: /* Tag it */ Clarify “entire Camino tree” compared to “entre repository”

<big>How to (branch and tag and build and) release a new version of Camino</big>
 
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 [http://www.caminobrowser.org/releases/1.0.4.php Camino 1.0.4] ([http://www.mozilla.com/en-US/firefox/releases/1.5.0.10.html Gecko 1.8.0.10]). The base tag for this release was <code>FIREFOX_1_5_0_10_RELEASE</code>. This specifies the apex of the minibranch. For the 1.0.4 release, changes to that tag for Camino were made on a new <code>CAMINO_1_0_4_MINIBRANCH</code> branch, and the release tag was <code>CAMINO_1_0_4_RELEASE</code>. Camino branch and release tags follow this convention (<code>CAMINO_1_1_A2_MINIBRANCH</code>, <code>CAMINO_1_1_B_RELEASE</code>).

== 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 <code>-D</code> when checking out <code>client.mk</code>, and set <code>MOZ_CO_DATE</code> when making <code>client.mk</code>’s <code>checkout</code> 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 [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.

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. <code>client.mk</code> 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 <code>client.mk</code> if that’s all that’s changing. After branching, use <code>cvs update</code> to move the tag on the files you’ll be working on, so that changes will be committed to the right branch. The usage here branches everything rooted at the current working directory (<code>mozilla</code>). 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 <code>FIREFOX_1_5_0_10_RELEASE</code> tag didn’t include changes to two Camino files that had been made recently on the <code>MOZILLA_1_8_0_BRANCH</code> in anticipation of Camino 1.0.4. I realized this because the release notes were missing. I found the other file by querying [http://bonsai.mozilla.org/ 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 <code>cvs tag -B -F</code> to move the tag because <code>ad_blocking.css</code> had already been branched. <code>cvs tag -B -F</code> 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 <code>client.mk</code> apply to the release tag ==

Now it’s possible to make changes to the working copy. First, update <code>client.mk</code> so that it will pull from the release tag (soon to be created). The relevant section of <code>client.mk</code> should look something like [http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/client.mk&rev=CAMINO_1_0_4_RELEASE&mark=241-245#236 this]. In this case, <code>sed</code> 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 <code>client.mk</code>. 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 [https://bugzilla.mozilla.org/buglist.cgi?status_whiteboard_type=substring&status_whiteboard=camino-1.0.3 querying Bugzilla for bugs with text like <code>camino-1.0.3</code>] in the status whiteboard field, by [http://bonsai.mozilla.org/cvsquery.cgi?branch=CAMINO_1_0_3_MINIBRANCH&date=all checking Bonsai for changes I made to the last release minibranch], or by asking [[User:Sardisson|Smokey]] or [[User:Admin|Sam]]. Those guys remember everything. These two things come from bugs [https://bugzilla.mozilla.org/show_bug.cgi?id=325765 325765] and [https://bugzilla.mozilla.org/show_bug.cgi?id=325964 325964]. When landing things on the minibranch, don’t forget to update the status whiteboard fields of the relevant bugs with text like <code>[camino-1.0.4]</code>.

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 [http://lxr.mozilla.org/mozilla/source/camino/docs/ReleaseChecklist.txt <code>camino/docs/ReleaseChecklist.txt</code>] 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 (<code>MOZILLA_1_8_0_BRANCH</code> 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 <code>client.mk</code> 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 <code>client.mk</code> by the <code>CAMINO_1_0_4_RELEASE</code> tag, then they’ll get what they expect. Change the tags in <code>client.mk</code> 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 <code>$CVSROOT</code>, 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 <code>$BuildTag</code> in <code>tinder-config.pl</code> to make sure it corresponds to your chosen release tag (or branch). When building from a tag (instead of a branch), pull-by-timestamp (<code>cvs checkout -D</code>) must be turned off. It’s useful when building from branches. Its behavior is controlled by the <code>$UseTimeStamp</code> 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 <code>multi-tinderbox</code>’ 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 <code>Cm1.0-M1.8.0</code> and adding a <code>Cm1.0.4</code> entry. Later, when the release is built, I’ll comment out <code>Cm1.0.4</code> and turn <code>Cm1.0-M1.8.0</code> back on. <code>multi-tinderbox</code> reloads its configuration when it receives a <code>SIGHUP</code>; 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 <code>multi-config.pl</code>.

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 <code>multi-tinderbox</code> to reload when the current build finishes:

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

When the release build begins, go to the [http://tinderbox.mozilla.org/Camino/ Camino tinderbox page], click “[http://tinderbox.mozilla.org/admintree.cgi?tree=Camino 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 your (my) mistakes|“fix-it”]] section above where I fixed <code>ad_blocking.css</code>, remembering that at this point, you’ve got both a <code>_MINIBRANCH</code> and <code>_RELEASE</code> 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 “[http://ftp.mozilla.org/pub/mozilla.org/camino/nightly/ nightly]” that tinderbox uploaded. If it seems reasonable, stage it and let people know. When possible, it’s nice to let the [http://caminol10n.mozdev.org/ 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 <code>/home/ftp/pub/camino/source/camino-1.0.4.tar.bz2</code>, and that directory has an <code>MD5SUMS</code> file as well. The multilingual release will go in
<code>/home/ftp/pub/camino/releases/Camino-1.0.4-MultiLang.dmg</code>, with a copy at <code>/home/ftp/pub/camino/releases/all/Camino-1.0.4.dmg</code>.

== Create a source release ==

We provide [http://ftp.mozilla.org/pub/mozilla.org/camino/source/ source tarballs] for major releases (not alphas, betas, or release candidates). Check out a fresh tree using anonymous CVS, so that the <code>CVS/Root</code> files are correct for people bootstrapping anonymous CVS workspaces. If the <code>.tar.bz2</code> 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|Stage it]].

== Have someone else set up Talkback reports ==

Ask Jay to set up [http://talkback-public.mozilla.org/reports/camino/ Talkback reports], at least until [http://code.google.com/p/google-breakpad/ Breakpad] is ready. Send him an e-mail with the relevant build information, like:

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

You can find this information from the <code>Contents/MacOS/components/talkback/master.ini</code> file from <code>Camino.app</code> 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.

* Wait for mirror propagation from <code>stage.mozilla.org</code> to all of the systems handling <code>releases.mozilla.org</code>, <code>ftp.mozilla.org</code>, and other mirrors.
* Have someone on the build team update bouncer. [https://bugzilla.mozilla.org/enter_bug.cgi?product=mozilla.org&component=Build%20%26%20Release File a bug in the “mozilla.org:Build & Release” component], or e-mail [mailto:build@mozilla.org build@mozilla.org]. If you forget how to accomplish this step, ask Reed. He’s always happy to remind us.
* Someone’s got to [[Releases:Website Checklist|update the website]], the web site, or both.
* Some releases include a “release notes” URL that needs to be populated with content or a redirect. The release notes URL is defined as <code>ReleaseNotesDefault</code> in [http://lxr.mozilla.org/mozilla1.8.0/source/camino/resources/application/WebsiteDefaults.strings <code>camino/resources/application/WebsiteDefaults.strings</code>] and is updated as part of the [[#Release checklist|release checklist]]. The URL used in Camino 1.0.4 is [http://www.mozilla.org/products/camino/releases/1.0.4.html], which redirects to [http://www.caminobrowser.org/releases/1.0.4.php].

Releases:Branch Tag Build Release

2007-03-01T21:03:14Z

Mento: /* Make <code>client.mk</code> apply to the release tag */ Rename section and provide a link to the client.mk change

<big>How to (branch and tag and build and) release a new version of Camino</big>
 
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 [http://www.caminobrowser.org/releases/1.0.4.php Camino 1.0.4] ([http://www.mozilla.com/en-US/firefox/releases/1.5.0.10.html Gecko 1.8.0.10]). The base tag for this release was <code>FIREFOX_1_5_0_10_RELEASE</code>. This specifies the apex of the minibranch. For the 1.0.4 release, changes to that tag for Camino were made on a new <code>CAMINO_1_0_4_MINIBRANCH</code> branch, and the release tag was <code>CAMINO_1_0_4_RELEASE</code>. Camino branch and release tags follow this convention (<code>CAMINO_1_1_A2_MINIBRANCH</code>, <code>CAMINO_1_1_B_RELEASE</code>).

== 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 <code>-D</code> when checking out <code>client.mk</code>, and set <code>MOZ_CO_DATE</code> when making <code>client.mk</code>’s <code>checkout</code> 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 [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.

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. <code>client.mk</code> 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 <code>client.mk</code> if that’s all that’s changing. After branching, use <code>cvs update</code> to move the tag on the files you’ll be working on, so that changes will be committed to the right branch. The usage here branches everything rooted at the current working directory (<code>mozilla</code>). 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 <code>FIREFOX_1_5_0_10_RELEASE</code> tag didn’t include changes to two Camino files that had been made recently on the <code>MOZILLA_1_8_0_BRANCH</code> in anticipation of Camino 1.0.4. I realized this because the release notes were missing. I found the other file by querying [http://bonsai.mozilla.org/ 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 <code>cvs tag -B -F</code> to move the tag because <code>ad_blocking.css</code> had already been branched. <code>cvs tag -B -F</code> 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 <code>client.mk</code> apply to the release tag ==

Now it’s possible to make changes to the working copy. First, update <code>client.mk</code> so that it will pull from the release tag (soon to be created). The relevant section of <code>client.mk</code> should look something like [http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/client.mk&rev=CAMINO_1_0_4_RELEASE&mark=241-245#236 this]. In this case, <code>sed</code> 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 <code>client.mk</code>. 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 [https://bugzilla.mozilla.org/buglist.cgi?status_whiteboard_type=substring&status_whiteboard=camino-1.0.3 querying Bugzilla for bugs with text like <code>camino-1.0.3</code>] in the status whiteboard field, by [http://bonsai.mozilla.org/cvsquery.cgi?branch=CAMINO_1_0_3_MINIBRANCH&date=all checking Bonsai for changes I made to the last release minibranch], or by asking [[User:Sardisson|Smokey]] or [[User:Admin|Sam]]. Those guys remember everything. These two things come from bugs [https://bugzilla.mozilla.org/show_bug.cgi?id=325765 325765] and [https://bugzilla.mozilla.org/show_bug.cgi?id=325964 325964]. When landing things on the minibranch, don’t forget to update the status whiteboard fields of the relevant bugs with text like <code>[camino-1.0.4]</code>.

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 [http://lxr.mozilla.org/mozilla/source/camino/docs/ReleaseChecklist.txt <code>camino/docs/ReleaseChecklist.txt</code>] 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 (<code>MOZILLA_1_8_0_BRANCH</code> 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 <code>client.mk</code> 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, even NSPR and NSS.

cvs tag CAMINO_1_0_4_RELEASE

If someone pulls <code>client.mk</code> by the <code>CAMINO_1_0_4_RELEASE</code> tag, then they’ll get what they expect. Change the tags in <code>client.mk</code> 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 <code>$CVSROOT</code>, 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 <code>$BuildTag</code> in <code>tinder-config.pl</code> to make sure it corresponds to your chosen release tag (or branch). When building from a tag (instead of a branch), pull-by-timestamp (<code>cvs checkout -D</code>) must be turned off. It’s useful when building from branches. Its behavior is controlled by the <code>$UseTimeStamp</code> 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 <code>multi-tinderbox</code>’ 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 <code>Cm1.0-M1.8.0</code> and adding a <code>Cm1.0.4</code> entry. Later, when the release is built, I’ll comment out <code>Cm1.0.4</code> and turn <code>Cm1.0-M1.8.0</code> back on. <code>multi-tinderbox</code> reloads its configuration when it receives a <code>SIGHUP</code>; 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 <code>multi-config.pl</code>.

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 <code>multi-tinderbox</code> to reload when the current build finishes:

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

When the release build begins, go to the [http://tinderbox.mozilla.org/Camino/ Camino tinderbox page], click “[http://tinderbox.mozilla.org/admintree.cgi?tree=Camino 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 your (my) mistakes|“fix-it”]] section above where I fixed <code>ad_blocking.css</code>, remembering that at this point, you’ve got both a <code>_MINIBRANCH</code> and <code>_RELEASE</code> 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 “[http://ftp.mozilla.org/pub/mozilla.org/camino/nightly/ nightly]” that tinderbox uploaded. If it seems reasonable, stage it and let people know. When possible, it’s nice to let the [http://caminol10n.mozdev.org/ 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 <code>/home/ftp/pub/camino/source/camino-1.0.4.tar.bz2</code>, and that directory has an <code>MD5SUMS</code> file as well. The multilingual release will go in
<code>/home/ftp/pub/camino/releases/Camino-1.0.4-MultiLang.dmg</code>, with a copy at <code>/home/ftp/pub/camino/releases/all/Camino-1.0.4.dmg</code>.

== Create a source release ==

We provide [http://ftp.mozilla.org/pub/mozilla.org/camino/source/ source tarballs] for major releases (not alphas, betas, or release candidates). Check out a fresh tree using anonymous CVS, so that the <code>CVS/Root</code> files are correct for people bootstrapping anonymous CVS workspaces. If the <code>.tar.bz2</code> 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|Stage it]].

== Have someone else set up Talkback reports ==

Ask Jay to set up [http://talkback-public.mozilla.org/reports/camino/ Talkback reports], at least until [http://code.google.com/p/google-breakpad/ Breakpad] is ready. Send him an e-mail with the relevant build information, like:

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

You can find this information from the <code>Contents/MacOS/components/talkback/master.ini</code> file from <code>Camino.app</code> 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.

* Wait for mirror propagation from <code>stage.mozilla.org</code> to all of the systems handling <code>releases.mozilla.org</code>, <code>ftp.mozilla.org</code>, and other mirrors.
* Have someone on the build team update bouncer. [https://bugzilla.mozilla.org/enter_bug.cgi?product=mozilla.org&component=Build%20%26%20Release File a bug in the “mozilla.org:Build & Release” component], or e-mail [mailto:build@mozilla.org build@mozilla.org]. If you forget how to accomplish this step, ask Reed. He’s always happy to remind us.
* Someone’s got to [[Releases:Website Checklist|update the website]], the web site, or both.
* Some releases include a “release notes” URL that needs to be populated with content or a redirect. The release notes URL is defined as <code>ReleaseNotesDefault</code> in [http://lxr.mozilla.org/mozilla1.8.0/source/camino/resources/application/WebsiteDefaults.strings <code>camino/resources/application/WebsiteDefaults.strings</code>] and is updated as part of the [[#Release checklist|release checklist]]. The URL used in Camino 1.0.4 is [http://www.mozilla.org/products/camino/releases/1.0.4.html], which redirects to [http://www.caminobrowser.org/releases/1.0.4.php].

Releases:Branch Tag Build Release

2007-03-01T20:57:27Z

Mento: /* Other things to do */

<big>How to (branch and tag and build and) release a new version of Camino</big>
 
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 [http://www.caminobrowser.org/releases/1.0.4.php Camino 1.0.4] ([http://www.mozilla.com/en-US/firefox/releases/1.5.0.10.html Gecko 1.8.0.10]). The base tag for this release was <code>FIREFOX_1_5_0_10_RELEASE</code>. This specifies the apex of the minibranch. For the 1.0.4 release, changes to that tag for Camino were made on a new <code>CAMINO_1_0_4_MINIBRANCH</code> branch, and the release tag was <code>CAMINO_1_0_4_RELEASE</code>. Camino branch and release tags follow this convention (<code>CAMINO_1_1_A2_MINIBRANCH</code>, <code>CAMINO_1_1_B_RELEASE</code>).

== 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 <code>-D</code> when checking out <code>client.mk</code>, and set <code>MOZ_CO_DATE</code> when making <code>client.mk</code>’s <code>checkout</code> 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 [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.

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. <code>client.mk</code> 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 <code>client.mk</code> if that’s all that’s changing. After branching, use <code>cvs update</code> to move the tag on the files you’ll be working on, so that changes will be committed to the right branch. The usage here branches everything rooted at the current working directory (<code>mozilla</code>). 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 <code>FIREFOX_1_5_0_10_RELEASE</code> tag didn’t include changes to two Camino files that had been made recently on the <code>MOZILLA_1_8_0_BRANCH</code> in anticipation of Camino 1.0.4. I realized this because the release notes were missing. I found the other file by querying [http://bonsai.mozilla.org/ 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 <code>cvs tag -B -F</code> to move the tag because <code>ad_blocking.css</code> had already been branched. <code>cvs tag -B -F</code> 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 <code>client.mk</code> apply to the minibranch ==

Now it’s possible to make changes to the working copy. First, update <code>client.mk</code> so that it will pull from the release tag (soon to be created). In this case, <code>sed</code> 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 <code>client.mk</code>. 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 [https://bugzilla.mozilla.org/buglist.cgi?status_whiteboard_type=substring&status_whiteboard=camino-1.0.3 querying Bugzilla for bugs with text like <code>camino-1.0.3</code>] in the status whiteboard field, by [http://bonsai.mozilla.org/cvsquery.cgi?branch=CAMINO_1_0_3_MINIBRANCH&date=all checking Bonsai for changes I made to the last release minibranch], or by asking [[User:Sardisson|Smokey]] or [[User:Admin|Sam]]. Those guys remember everything. These two things come from bugs [https://bugzilla.mozilla.org/show_bug.cgi?id=325765 325765] and [https://bugzilla.mozilla.org/show_bug.cgi?id=325964 325964]. When landing things on the minibranch, don’t forget to update the status whiteboard fields of the relevant bugs with text like <code>[camino-1.0.4]</code>.

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 [http://lxr.mozilla.org/mozilla/source/camino/docs/ReleaseChecklist.txt <code>camino/docs/ReleaseChecklist.txt</code>] 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 (<code>MOZILLA_1_8_0_BRANCH</code> 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 <code>client.mk</code> 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, even NSPR and NSS.

cvs tag CAMINO_1_0_4_RELEASE

If someone pulls <code>client.mk</code> by the <code>CAMINO_1_0_4_RELEASE</code> tag, then they’ll get what they expect. Change the tags in <code>client.mk</code> 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 <code>$CVSROOT</code>, 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 <code>$BuildTag</code> in <code>tinder-config.pl</code> to make sure it corresponds to your chosen release tag (or branch). When building from a tag (instead of a branch), pull-by-timestamp (<code>cvs checkout -D</code>) must be turned off. It’s useful when building from branches. Its behavior is controlled by the <code>$UseTimeStamp</code> 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 <code>multi-tinderbox</code>’ 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 <code>Cm1.0-M1.8.0</code> and adding a <code>Cm1.0.4</code> entry. Later, when the release is built, I’ll comment out <code>Cm1.0.4</code> and turn <code>Cm1.0-M1.8.0</code> back on. <code>multi-tinderbox</code> reloads its configuration when it receives a <code>SIGHUP</code>; 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 <code>multi-config.pl</code>.

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 <code>multi-tinderbox</code> to reload when the current build finishes:

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

When the release build begins, go to the [http://tinderbox.mozilla.org/Camino/ Camino tinderbox page], click “[http://tinderbox.mozilla.org/admintree.cgi?tree=Camino 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 your (my) mistakes|“fix-it”]] section above where I fixed <code>ad_blocking.css</code>, remembering that at this point, you’ve got both a <code>_MINIBRANCH</code> and <code>_RELEASE</code> 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 “[http://ftp.mozilla.org/pub/mozilla.org/camino/nightly/ nightly]” that tinderbox uploaded. If it seems reasonable, stage it and let people know. When possible, it’s nice to let the [http://caminol10n.mozdev.org/ 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 <code>/home/ftp/pub/camino/source/camino-1.0.4.tar.bz2</code>, and that directory has an <code>MD5SUMS</code> file as well. The multilingual release will go in
<code>/home/ftp/pub/camino/releases/Camino-1.0.4-MultiLang.dmg</code>, with a copy at <code>/home/ftp/pub/camino/releases/all/Camino-1.0.4.dmg</code>.

== Create a source release ==

We provide [http://ftp.mozilla.org/pub/mozilla.org/camino/source/ source tarballs] for major releases (not alphas, betas, or release candidates). Check out a fresh tree using anonymous CVS, so that the <code>CVS/Root</code> files are correct for people bootstrapping anonymous CVS workspaces. If the <code>.tar.bz2</code> 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|Stage it]].

== Have someone else set up Talkback reports ==

Ask Jay to set up [http://talkback-public.mozilla.org/reports/camino/ Talkback reports], at least until [http://code.google.com/p/google-breakpad/ Breakpad] is ready. Send him an e-mail with the relevant build information, like:

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

You can find this information from the <code>Contents/MacOS/components/talkback/master.ini</code> file from <code>Camino.app</code> 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.

* Wait for mirror propagation from <code>stage.mozilla.org</code> to all of the systems handling <code>releases.mozilla.org</code>, <code>ftp.mozilla.org</code>, and other mirrors.
* Have someone on the build team update bouncer. [https://bugzilla.mozilla.org/enter_bug.cgi?product=mozilla.org&component=Build%20%26%20Release File a bug in the “mozilla.org:Build & Release” component], or e-mail [mailto:build@mozilla.org build@mozilla.org]. If you forget how to accomplish this step, ask Reed. He’s always happy to remind us.
* Someone’s got to [[Releases:Website Checklist|update the website]], the web site, or both.
* Some releases include a “release notes” URL that needs to be populated with content or a redirect. The release notes URL is defined as <code>ReleaseNotesDefault</code> in [http://lxr.mozilla.org/mozilla1.8.0/source/camino/resources/application/WebsiteDefaults.strings <code>camino/resources/application/WebsiteDefaults.strings</code>] and is updated as part of the [[#Release checklist|release checklist]]. The URL used in Camino 1.0.4 is [http://www.mozilla.org/products/camino/releases/1.0.4.html], which redirects to [http://www.caminobrowser.org/releases/1.0.4.php].

Releases:Branch Tag Build Release

2007-03-01T20:56:46Z

Mento: /* Other things to do */

<big>How to (branch and tag and build and) release a new version of Camino</big>
 
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 [http://www.caminobrowser.org/releases/1.0.4.php Camino 1.0.4] ([http://www.mozilla.com/en-US/firefox/releases/1.5.0.10.html Gecko 1.8.0.10]). The base tag for this release was <code>FIREFOX_1_5_0_10_RELEASE</code>. This specifies the apex of the minibranch. For the 1.0.4 release, changes to that tag for Camino were made on a new <code>CAMINO_1_0_4_MINIBRANCH</code> branch, and the release tag was <code>CAMINO_1_0_4_RELEASE</code>. Camino branch and release tags follow this convention (<code>CAMINO_1_1_A2_MINIBRANCH</code>, <code>CAMINO_1_1_B_RELEASE</code>).

== 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 <code>-D</code> when checking out <code>client.mk</code>, and set <code>MOZ_CO_DATE</code> when making <code>client.mk</code>’s <code>checkout</code> 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 [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.

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. <code>client.mk</code> 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 <code>client.mk</code> if that’s all that’s changing. After branching, use <code>cvs update</code> to move the tag on the files you’ll be working on, so that changes will be committed to the right branch. The usage here branches everything rooted at the current working directory (<code>mozilla</code>). 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 <code>FIREFOX_1_5_0_10_RELEASE</code> tag didn’t include changes to two Camino files that had been made recently on the <code>MOZILLA_1_8_0_BRANCH</code> in anticipation of Camino 1.0.4. I realized this because the release notes were missing. I found the other file by querying [http://bonsai.mozilla.org/ 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 <code>cvs tag -B -F</code> to move the tag because <code>ad_blocking.css</code> had already been branched. <code>cvs tag -B -F</code> 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 <code>client.mk</code> apply to the minibranch ==

Now it’s possible to make changes to the working copy. First, update <code>client.mk</code> so that it will pull from the release tag (soon to be created). In this case, <code>sed</code> 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 <code>client.mk</code>. 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 [https://bugzilla.mozilla.org/buglist.cgi?status_whiteboard_type=substring&status_whiteboard=camino-1.0.3 querying Bugzilla for bugs with text like <code>camino-1.0.3</code>] in the status whiteboard field, by [http://bonsai.mozilla.org/cvsquery.cgi?branch=CAMINO_1_0_3_MINIBRANCH&date=all checking Bonsai for changes I made to the last release minibranch], or by asking [[User:Sardisson|Smokey]] or [[User:Admin|Sam]]. Those guys remember everything. These two things come from bugs [https://bugzilla.mozilla.org/show_bug.cgi?id=325765 325765] and [https://bugzilla.mozilla.org/show_bug.cgi?id=325964 325964]. When landing things on the minibranch, don’t forget to update the status whiteboard fields of the relevant bugs with text like <code>[camino-1.0.4]</code>.

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 [http://lxr.mozilla.org/mozilla/source/camino/docs/ReleaseChecklist.txt <code>camino/docs/ReleaseChecklist.txt</code>] 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 (<code>MOZILLA_1_8_0_BRANCH</code> 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 <code>client.mk</code> 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, even NSPR and NSS.

cvs tag CAMINO_1_0_4_RELEASE

If someone pulls <code>client.mk</code> by the <code>CAMINO_1_0_4_RELEASE</code> tag, then they’ll get what they expect. Change the tags in <code>client.mk</code> 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 <code>$CVSROOT</code>, 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 <code>$BuildTag</code> in <code>tinder-config.pl</code> to make sure it corresponds to your chosen release tag (or branch). When building from a tag (instead of a branch), pull-by-timestamp (<code>cvs checkout -D</code>) must be turned off. It’s useful when building from branches. Its behavior is controlled by the <code>$UseTimeStamp</code> 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 <code>multi-tinderbox</code>’ 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 <code>Cm1.0-M1.8.0</code> and adding a <code>Cm1.0.4</code> entry. Later, when the release is built, I’ll comment out <code>Cm1.0.4</code> and turn <code>Cm1.0-M1.8.0</code> back on. <code>multi-tinderbox</code> reloads its configuration when it receives a <code>SIGHUP</code>; 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 <code>multi-config.pl</code>.

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 <code>multi-tinderbox</code> to reload when the current build finishes:

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

When the release build begins, go to the [http://tinderbox.mozilla.org/Camino/ Camino tinderbox page], click “[http://tinderbox.mozilla.org/admintree.cgi?tree=Camino 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 your (my) mistakes|“fix-it”]] section above where I fixed <code>ad_blocking.css</code>, remembering that at this point, you’ve got both a <code>_MINIBRANCH</code> and <code>_RELEASE</code> 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 “[http://ftp.mozilla.org/pub/mozilla.org/camino/nightly/ nightly]” that tinderbox uploaded. If it seems reasonable, stage it and let people know. When possible, it’s nice to let the [http://caminol10n.mozdev.org/ 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 <code>/home/ftp/pub/camino/source/camino-1.0.4.tar.bz2</code>, and that directory has an <code>MD5SUMS</code> file as well. The multilingual release will go in
<code>/home/ftp/pub/camino/releases/Camino-1.0.4-MultiLang.dmg</code>, with a copy at <code>/home/ftp/pub/camino/releases/all/Camino-1.0.4.dmg</code>.

== Create a source release ==

We provide [http://ftp.mozilla.org/pub/mozilla.org/camino/source/ source tarballs] for major releases (not alphas, betas, or release candidates). Check out a fresh tree using anonymous CVS, so that the <code>CVS/Root</code> files are correct for people bootstrapping anonymous CVS workspaces. If the <code>.tar.bz2</code> 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|Stage it]].

== Have someone else set up Talkback reports ==

Ask Jay to set up [http://talkback-public.mozilla.org/reports/camino/ Talkback reports], at least until [http://code.google.com/p/google-breakpad/ Breakpad] is ready. Send him an e-mail with the relevant build information, like:

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

You can find this information from the <code>Contents/MacOS/components/talkback/master.ini</code> file from <code>Camino.app</code> 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.

* Wait for mirror propagation from <code>stage.mozilla.org</code> to all of the systems handling <code>releases.mozilla.org</code>, <code>ftp.mozilla.org</code>, and other mirrors.
* Have someone on the build team update bouncer. [https://bugzilla.mozilla.org/enter_bug.cgi?product=mozilla.org&component=Build%20%26%20Release File a bug in the “mozilla.org:Build & Release” component], or e-mail [mailto:build@mozilla.org build@mozilla.org]. If you forget how to accomplish this step, ask Reed. He's always happy to remind us.
* Someone’s got to [[Releases:Website Checklist|update the website]], the web site, or both.
* Some releases include a “release notes” URL that needs to be populated with content or a redirect. The release notes URL is defined as <code>ReleaseNotesDefault</code> in [http://lxr.mozilla.org/mozilla1.8.0/source/camino/resources/application/WebsiteDefaults.strings <code>camino/resources/application/WebsiteDefaults.strings</code>] and is updated as part of the [[#Release checklist|release checklist]]. The URL used in Camino 1.0.4 is [http://www.mozilla.org/products/camino/releases/1.0.4.html], which redirects to [http://www.caminobrowser.org/releases/1.0.4.php].

Releases:Branch Tag Build Release

2007-03-01T20:55:16Z

Mento: /* Other things to do */ New bug link

<big>How to (branch and tag and build and) release a new version of Camino</big>
 
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 [http://www.caminobrowser.org/releases/1.0.4.php Camino 1.0.4] ([http://www.mozilla.com/en-US/firefox/releases/1.5.0.10.html Gecko 1.8.0.10]). The base tag for this release was <code>FIREFOX_1_5_0_10_RELEASE</code>. This specifies the apex of the minibranch. For the 1.0.4 release, changes to that tag for Camino were made on a new <code>CAMINO_1_0_4_MINIBRANCH</code> branch, and the release tag was <code>CAMINO_1_0_4_RELEASE</code>. Camino branch and release tags follow this convention (<code>CAMINO_1_1_A2_MINIBRANCH</code>, <code>CAMINO_1_1_B_RELEASE</code>).

== 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 <code>-D</code> when checking out <code>client.mk</code>, and set <code>MOZ_CO_DATE</code> when making <code>client.mk</code>’s <code>checkout</code> 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 [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.

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. <code>client.mk</code> 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 <code>client.mk</code> if that’s all that’s changing. After branching, use <code>cvs update</code> to move the tag on the files you’ll be working on, so that changes will be committed to the right branch. The usage here branches everything rooted at the current working directory (<code>mozilla</code>). 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 <code>FIREFOX_1_5_0_10_RELEASE</code> tag didn’t include changes to two Camino files that had been made recently on the <code>MOZILLA_1_8_0_BRANCH</code> in anticipation of Camino 1.0.4. I realized this because the release notes were missing. I found the other file by querying [http://bonsai.mozilla.org/ 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 <code>cvs tag -B -F</code> to move the tag because <code>ad_blocking.css</code> had already been branched. <code>cvs tag -B -F</code> 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 <code>client.mk</code> apply to the minibranch ==

Now it’s possible to make changes to the working copy. First, update <code>client.mk</code> so that it will pull from the release tag (soon to be created). In this case, <code>sed</code> 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 <code>client.mk</code>. 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 [https://bugzilla.mozilla.org/buglist.cgi?status_whiteboard_type=substring&status_whiteboard=camino-1.0.3 querying Bugzilla for bugs with text like <code>camino-1.0.3</code>] in the status whiteboard field, by [http://bonsai.mozilla.org/cvsquery.cgi?branch=CAMINO_1_0_3_MINIBRANCH&date=all checking Bonsai for changes I made to the last release minibranch], or by asking [[User:Sardisson|Smokey]] or [[User:Admin|Sam]]. Those guys remember everything. These two things come from bugs [https://bugzilla.mozilla.org/show_bug.cgi?id=325765 325765] and [https://bugzilla.mozilla.org/show_bug.cgi?id=325964 325964]. When landing things on the minibranch, don’t forget to update the status whiteboard fields of the relevant bugs with text like <code>[camino-1.0.4]</code>.

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 [http://lxr.mozilla.org/mozilla/source/camino/docs/ReleaseChecklist.txt <code>camino/docs/ReleaseChecklist.txt</code>] 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 (<code>MOZILLA_1_8_0_BRANCH</code> 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 <code>client.mk</code> 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, even NSPR and NSS.

cvs tag CAMINO_1_0_4_RELEASE

If someone pulls <code>client.mk</code> by the <code>CAMINO_1_0_4_RELEASE</code> tag, then they’ll get what they expect. Change the tags in <code>client.mk</code> 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 <code>$CVSROOT</code>, 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 <code>$BuildTag</code> in <code>tinder-config.pl</code> to make sure it corresponds to your chosen release tag (or branch). When building from a tag (instead of a branch), pull-by-timestamp (<code>cvs checkout -D</code>) must be turned off. It’s useful when building from branches. Its behavior is controlled by the <code>$UseTimeStamp</code> 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 <code>multi-tinderbox</code>’ 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 <code>Cm1.0-M1.8.0</code> and adding a <code>Cm1.0.4</code> entry. Later, when the release is built, I’ll comment out <code>Cm1.0.4</code> and turn <code>Cm1.0-M1.8.0</code> back on. <code>multi-tinderbox</code> reloads its configuration when it receives a <code>SIGHUP</code>; 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 <code>multi-config.pl</code>.

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 <code>multi-tinderbox</code> to reload when the current build finishes:

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

When the release build begins, go to the [http://tinderbox.mozilla.org/Camino/ Camino tinderbox page], click “[http://tinderbox.mozilla.org/admintree.cgi?tree=Camino 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 your (my) mistakes|“fix-it”]] section above where I fixed <code>ad_blocking.css</code>, remembering that at this point, you’ve got both a <code>_MINIBRANCH</code> and <code>_RELEASE</code> 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 “[http://ftp.mozilla.org/pub/mozilla.org/camino/nightly/ nightly]” that tinderbox uploaded. If it seems reasonable, stage it and let people know. When possible, it’s nice to let the [http://caminol10n.mozdev.org/ 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 <code>/home/ftp/pub/camino/source/camino-1.0.4.tar.bz2</code>, and that directory has an <code>MD5SUMS</code> file as well. The multilingual release will go in
<code>/home/ftp/pub/camino/releases/Camino-1.0.4-MultiLang.dmg</code>, with a copy at <code>/home/ftp/pub/camino/releases/all/Camino-1.0.4.dmg</code>.

== Create a source release ==

We provide [http://ftp.mozilla.org/pub/mozilla.org/camino/source/ source tarballs] for major releases (not alphas, betas, or release candidates). Check out a fresh tree using anonymous CVS, so that the <code>CVS/Root</code> files are correct for people bootstrapping anonymous CVS workspaces. If the <code>.tar.bz2</code> 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|Stage it]].

== Have someone else set up Talkback reports ==

Ask Jay to set up [http://talkback-public.mozilla.org/reports/camino/ Talkback reports], at least until [http://code.google.com/p/google-breakpad/ Breakpad] is ready. Send him an e-mail with the relevant build information, like:

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

You can find this information from the <code>Contents/MacOS/components/talkback/master.ini</code> file from <code>Camino.app</code> 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.

* Wait for mirror propagation from <code>stage.mozilla.org</code> to all of the systems handling <code>releases.mozilla.org</code>, <code>ftp.mozilla.org</code>, and other mirrors.
* Have someone on the build team update bouncer. [https://bugzilla.mozilla.org/enter_bug.cgi?product=mozilla.org&component=Build%20%26%20Release File a bug in the “mozilla.org:Build & Release” component], or e-mail [mailto:build@mozilla.org build@mozilla.org]. If you forget how to accomplish this step, ask Reed. He's always happy to remind us.
* Someone’s got to [[Releases:Website Checklist|update the website]], the web site, or both.
* Some releases include a “release notes” URL that needs to be populated with content or a redirect. The release notes URL is defined as <code>ReleaseNotesDefault</code> in [http://lxr.mozilla.org/mozilla1.8.0/source/camino/resources/application/WebsiteDefaults.strings <code>camino/resources/application/WebsiteDefaults.strings</code>] and is updated as part of the [[#Release checklist|release checklist]]. The URL for Camino 1.0.4 is [http://www.mozilla.org/products/camino/releases/1.0.4.html], which redirects to [http://www.caminobrowser.org/releases/1.0.4.php].

Releases:Branch Tag Build Release

2007-03-01T20:47:45Z

Mento: /* Other things to do */ New section

<big>How to (branch and tag and build and) release a new version of Camino</big>
 
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 [http://www.caminobrowser.org/releases/1.0.4.php Camino 1.0.4] ([http://www.mozilla.com/en-US/firefox/releases/1.5.0.10.html Gecko 1.8.0.10]). The base tag for this release was <code>FIREFOX_1_5_0_10_RELEASE</code>. This specifies the apex of the minibranch. For the 1.0.4 release, changes to that tag for Camino were made on a new <code>CAMINO_1_0_4_MINIBRANCH</code> branch, and the release tag was <code>CAMINO_1_0_4_RELEASE</code>. Camino branch and release tags follow this convention (<code>CAMINO_1_1_A2_MINIBRANCH</code>, <code>CAMINO_1_1_B_RELEASE</code>).

== 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 <code>-D</code> when checking out <code>client.mk</code>, and set <code>MOZ_CO_DATE</code> when making <code>client.mk</code>’s <code>checkout</code> 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 [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.

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. <code>client.mk</code> 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 <code>client.mk</code> if that’s all that’s changing. After branching, use <code>cvs update</code> to move the tag on the files you’ll be working on, so that changes will be committed to the right branch. The usage here branches everything rooted at the current working directory (<code>mozilla</code>). 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 <code>FIREFOX_1_5_0_10_RELEASE</code> tag didn’t include changes to two Camino files that had been made recently on the <code>MOZILLA_1_8_0_BRANCH</code> in anticipation of Camino 1.0.4. I realized this because the release notes were missing. I found the other file by querying [http://bonsai.mozilla.org/ 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 <code>cvs tag -B -F</code> to move the tag because <code>ad_blocking.css</code> had already been branched. <code>cvs tag -B -F</code> 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 <code>client.mk</code> apply to the minibranch ==

Now it’s possible to make changes to the working copy. First, update <code>client.mk</code> so that it will pull from the release tag (soon to be created). In this case, <code>sed</code> 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 <code>client.mk</code>. 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 [https://bugzilla.mozilla.org/buglist.cgi?status_whiteboard_type=substring&status_whiteboard=camino-1.0.3 querying Bugzilla for bugs with text like <code>camino-1.0.3</code>] in the status whiteboard field, by [http://bonsai.mozilla.org/cvsquery.cgi?branch=CAMINO_1_0_3_MINIBRANCH&date=all checking Bonsai for changes I made to the last release minibranch], or by asking [[User:Sardisson|Smokey]] or [[User:Admin|Sam]]. Those guys remember everything. These two things come from bugs [https://bugzilla.mozilla.org/show_bug.cgi?id=325765 325765] and [https://bugzilla.mozilla.org/show_bug.cgi?id=325964 325964]. When landing things on the minibranch, don’t forget to update the status whiteboard fields of the relevant bugs with text like <code>[camino-1.0.4]</code>.

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 [http://lxr.mozilla.org/mozilla/source/camino/docs/ReleaseChecklist.txt <code>camino/docs/ReleaseChecklist.txt</code>] 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 (<code>MOZILLA_1_8_0_BRANCH</code> 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 <code>client.mk</code> 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, even NSPR and NSS.

cvs tag CAMINO_1_0_4_RELEASE

If someone pulls <code>client.mk</code> by the <code>CAMINO_1_0_4_RELEASE</code> tag, then they’ll get what they expect. Change the tags in <code>client.mk</code> 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 <code>$CVSROOT</code>, 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 <code>$BuildTag</code> in <code>tinder-config.pl</code> to make sure it corresponds to your chosen release tag (or branch). When building from a tag (instead of a branch), pull-by-timestamp (<code>cvs checkout -D</code>) must be turned off. It’s useful when building from branches. Its behavior is controlled by the <code>$UseTimeStamp</code> 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 <code>multi-tinderbox</code>’ 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 <code>Cm1.0-M1.8.0</code> and adding a <code>Cm1.0.4</code> entry. Later, when the release is built, I’ll comment out <code>Cm1.0.4</code> and turn <code>Cm1.0-M1.8.0</code> back on. <code>multi-tinderbox</code> reloads its configuration when it receives a <code>SIGHUP</code>; 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 <code>multi-config.pl</code>.

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 <code>multi-tinderbox</code> to reload when the current build finishes:

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

When the release build begins, go to the [http://tinderbox.mozilla.org/Camino/ Camino tinderbox page], click “[http://tinderbox.mozilla.org/admintree.cgi?tree=Camino 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 your (my) mistakes|“fix-it”]] section above where I fixed <code>ad_blocking.css</code>, remembering that at this point, you’ve got both a <code>_MINIBRANCH</code> and <code>_RELEASE</code> 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 “[http://ftp.mozilla.org/pub/mozilla.org/camino/nightly/ nightly]” that tinderbox uploaded. If it seems reasonable, stage it and let people know. When possible, it’s nice to let the [http://caminol10n.mozdev.org/ 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 <code>/home/ftp/pub/camino/source/camino-1.0.4.tar.bz2</code>, and that directory has an <code>MD5SUMS</code> file as well. The multilingual release will go in
<code>/home/ftp/pub/camino/releases/Camino-1.0.4-MultiLang.dmg</code>, with a copy at <code>/home/ftp/pub/camino/releases/all/Camino-1.0.4.dmg</code>.

== Create a source release ==

We provide [http://ftp.mozilla.org/pub/mozilla.org/camino/source/ source tarballs] for major releases (not alphas, betas, or release candidates). Check out a fresh tree using anonymous CVS, so that the <code>CVS/Root</code> files are correct for people bootstrapping anonymous CVS workspaces. If the <code>.tar.bz2</code> 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|Stage it]].

== Have someone else set up Talkback reports ==

Ask Jay to set up [http://talkback-public.mozilla.org/reports/camino/ Talkback reports], at least until [http://code.google.com/p/google-breakpad/ Breakpad] is ready. Send him an e-mail with the relevant build information, like:

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

You can find this information from the <code>Contents/MacOS/components/talkback/master.ini</code> file from <code>Camino.app</code> 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.

* Wait for mirror propagation from <code>stage.mozilla.org</code> to all of the systems handling <code>releases.mozilla.org</code>, <code>ftp.mozilla.org</code>, and other mirrors.
* Have someone on the build team update bouncer. File a bug in the “mozilla.org:Build & Release” component, or e-mail [mailto:build@mozilla.org build@mozilla.org].
* Someone’s got to [[Releases:Website Checklist|update the website]], the web site, or both.
* Some releases include a “release notes” URL that needs to be populated with content or a redirect. The release notes URL is defined as <code>ReleaseNotesDefault</code> in [http://lxr.mozilla.org/mozilla1.8.0/source/camino/resources/application/WebsiteDefaults.strings <code>camino/resources/application/WebsiteDefaults.strings</code>] and is updated as part of the [[#Release checklist|release checklist]]. The URL for Camino 1.0.4 is [http://www.mozilla.org/products/camino/releases/1.0.4.html], which redirects to [http://www.caminobrowser.org/releases/1.0.4.php].

Releases:Branch Tag Build Release

2007-03-01T19:41:56Z

Mento: /* Release checklist */ I lost my parenthesis

<big>How to (branch and tag and build and) release a new version of Camino</big>
 
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 [http://www.caminobrowser.org/releases/1.0.4.php Camino 1.0.4] ([http://www.mozilla.com/en-US/firefox/releases/1.5.0.10.html Gecko 1.8.0.10]). The base tag for this release was <code>FIREFOX_1_5_0_10_RELEASE</code>. This specifies the apex of the minibranch. For the 1.0.4 release, changes to that tag for Camino were made on a new <code>CAMINO_1_0_4_MINIBRANCH</code> branch, and the release tag was <code>CAMINO_1_0_4_RELEASE</code>. Camino branch and release tags follow this convention (<code>CAMINO_1_1_A2_MINIBRANCH</code>, <code>CAMINO_1_1_B_RELEASE</code>).

== 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 <code>-D</code> when checking out <code>client.mk</code>, and set <code>MOZ_CO_DATE</code> when making <code>client.mk</code>’s <code>checkout</code> 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 [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.

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. <code>client.mk</code> 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 <code>client.mk</code> if that’s all that’s changing. After branching, use <code>cvs update</code> to move the tag on the files you’ll be working on, so that changes will be committed to the right branch. The usage here branches everything rooted at the current working directory (<code>mozilla</code>). 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 <code>FIREFOX_1_5_0_10_RELEASE</code> tag didn’t include changes to two Camino files that had been made recently on the <code>MOZILLA_1_8_0_BRANCH</code> in anticipation of Camino 1.0.4. I realized this because the release notes were missing. I found the other file by querying [http://bonsai.mozilla.org/ 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 <code>cvs tag -B -F</code> to move the tag because <code>ad_blocking.css</code> had already been branched. <code>cvs tag -B -F</code> 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 <code>client.mk</code> apply to the minibranch ==

Now it’s possible to make changes to the working copy. First, update <code>client.mk</code> so that it will pull from the release tag (soon to be created). In this case, <code>sed</code> 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 <code>client.mk</code>. 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 [https://bugzilla.mozilla.org/buglist.cgi?status_whiteboard_type=substring&status_whiteboard=camino-1.0.3 querying Bugzilla for bugs with text like <code>camino-1.0.3</code>] in the status whiteboard field, by [http://bonsai.mozilla.org/cvsquery.cgi?branch=CAMINO_1_0_3_MINIBRANCH&date=all checking Bonsai for changes I made to the last release minibranch], or by asking [[User:Sardisson|Smokey]] or [[User:Admin|Sam]]. Those guys remember everything. These two things come from bugs [https://bugzilla.mozilla.org/show_bug.cgi?id=325765 325765] and [https://bugzilla.mozilla.org/show_bug.cgi?id=325964 325964]. When landing things on the minibranch, don’t forget to update the status whiteboard fields of the relevant bugs with text like <code>[camino-1.0.4]</code>.

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 [http://lxr.mozilla.org/mozilla/source/camino/docs/ReleaseChecklist.txt <code>camino/docs/ReleaseChecklist.txt</code>] 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 (<code>MOZILLA_1_8_0_BRANCH</code> 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 <code>client.mk</code> 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, even NSPR and NSS.

cvs tag CAMINO_1_0_4_RELEASE

If someone pulls <code>client.mk</code> by the <code>CAMINO_1_0_4_RELEASE</code> tag, then they’ll get what they expect. Change the tags in <code>client.mk</code> 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 <code>$CVSROOT</code>, 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 <code>$BuildTag</code> in <code>tinder-config.pl</code> to make sure it corresponds to your chosen release tag (or branch). When building from a tag (instead of a branch), pull-by-timestamp (<code>cvs checkout -D</code>) must be turned off. It’s useful when building from branches. Its behavior is controlled by the <code>$UseTimeStamp</code> 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 <code>multi-tinderbox</code>’ 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 <code>Cm1.0-M1.8.0</code> and adding a <code>Cm1.0.4</code> entry. Later, when the release is built, I’ll comment out <code>Cm1.0.4</code> and turn <code>Cm1.0-M1.8.0</code> back on. <code>multi-tinderbox</code> reloads its configuration when it receives a <code>SIGHUP</code>; 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 <code>multi-config.pl</code>.

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 <code>multi-tinderbox</code> to reload when the current build finishes:

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

When the release build begins, go to the [http://tinderbox.mozilla.org/Camino/ Camino tinderbox page], click “[http://tinderbox.mozilla.org/admintree.cgi?tree=Camino 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 your (my) mistakes|“fix-it”]] section above where I fixed <code>ad_blocking.css</code>, remembering that at this point, you’ve got both a <code>_MINIBRANCH</code> and <code>_RELEASE</code> 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 “[http://ftp.mozilla.org/pub/mozilla.org/camino/nightly/ nightly]” that tinderbox uploaded. If it seems reasonable, stage it and let people know. When possible, it’s nice to let the [http://caminol10n.mozdev.org/ 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 <code>/home/ftp/pub/camino/source/camino-1.0.4.tar.bz2</code>, and that directory has an <code>MD5SUMS</code> file as well. The multilingual release will go in
<code>/home/ftp/pub/camino/releases/Camino-1.0.4-MultiLang.dmg</code>, with a copy at <code>/home/ftp/pub/camino/releases/all/Camino-1.0.4.dmg</code>.

== Create a source release ==

We provide [http://ftp.mozilla.org/pub/mozilla.org/camino/source/ source tarballs] for major releases (not alphas, betas, or release candidates). Check out a fresh tree using anonymous CVS, so that the <code>CVS/Root</code> files are correct for people bootstrapping anonymous CVS workspaces. If the <code>.tar.bz2</code> 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|Stage it]].

== Have someone else set up Talkback reports ==

Ask Jay to set up [http://talkback-public.mozilla.org/reports/camino/ Talkback reports], at least until [http://code.google.com/p/google-breakpad/ Breakpad] is ready. Send him an e-mail with the relevant build information, like:

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

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

Releases:Branch Tag Build Release

2007-03-01T19:39:27Z

Mento: /* Create a source release */ linku

<big>How to (branch and tag and build and) release a new version of Camino</big>
 
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 [http://www.caminobrowser.org/releases/1.0.4.php Camino 1.0.4] ([http://www.mozilla.com/en-US/firefox/releases/1.5.0.10.html Gecko 1.8.0.10]). The base tag for this release was <code>FIREFOX_1_5_0_10_RELEASE</code>. This specifies the apex of the minibranch. For the 1.0.4 release, changes to that tag for Camino were made on a new <code>CAMINO_1_0_4_MINIBRANCH</code> branch, and the release tag was <code>CAMINO_1_0_4_RELEASE</code>. Camino branch and release tags follow this convention (<code>CAMINO_1_1_A2_MINIBRANCH</code>, <code>CAMINO_1_1_B_RELEASE</code>).

== 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 <code>-D</code> when checking out <code>client.mk</code>, and set <code>MOZ_CO_DATE</code> when making <code>client.mk</code>’s <code>checkout</code> 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 [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.

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. <code>client.mk</code> 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 <code>client.mk</code> if that’s all that’s changing. After branching, use <code>cvs update</code> to move the tag on the files you’ll be working on, so that changes will be committed to the right branch. The usage here branches everything rooted at the current working directory (<code>mozilla</code>). 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 <code>FIREFOX_1_5_0_10_RELEASE</code> tag didn’t include changes to two Camino files that had been made recently on the <code>MOZILLA_1_8_0_BRANCH</code> in anticipation of Camino 1.0.4. I realized this because the release notes were missing. I found the other file by querying [http://bonsai.mozilla.org/ 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 <code>cvs tag -B -F</code> to move the tag because <code>ad_blocking.css</code> had already been branched. <code>cvs tag -B -F</code> 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 <code>client.mk</code> apply to the minibranch ==

Now it’s possible to make changes to the working copy. First, update <code>client.mk</code> so that it will pull from the release tag (soon to be created). In this case, <code>sed</code> 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 <code>client.mk</code>. 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 [https://bugzilla.mozilla.org/buglist.cgi?status_whiteboard_type=substring&status_whiteboard=camino-1.0.3 querying Bugzilla for bugs with text like <code>camino-1.0.3</code>] in the status whiteboard field, by [http://bonsai.mozilla.org/cvsquery.cgi?branch=CAMINO_1_0_3_MINIBRANCH&date=all checking Bonsai for changes I made to the last release minibranch], or by asking [[User:Sardisson|Smokey]] or [[User:Admin|Sam]]. Those guys remember everything. These two things come from bugs [https://bugzilla.mozilla.org/show_bug.cgi?id=325765 325765] and [https://bugzilla.mozilla.org/show_bug.cgi?id=325964 325964]. When landing things on the minibranch, don’t forget to update the status whiteboard fields of the relevant bugs with text like <code>[camino-1.0.4]</code>.

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 [http://lxr.mozilla.org/mozilla/source/camino/docs/ReleaseChecklist.txt <code>camino/docs/ReleaseChecklist.txt</code>] 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 <code>MOZILLA_1_8_0_BRANCH</code> 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 <code>client.mk</code> 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, even NSPR and NSS.

cvs tag CAMINO_1_0_4_RELEASE

If someone pulls <code>client.mk</code> by the <code>CAMINO_1_0_4_RELEASE</code> tag, then they’ll get what they expect. Change the tags in <code>client.mk</code> 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 <code>$CVSROOT</code>, 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 <code>$BuildTag</code> in <code>tinder-config.pl</code> to make sure it corresponds to your chosen release tag (or branch). When building from a tag (instead of a branch), pull-by-timestamp (<code>cvs checkout -D</code>) must be turned off. It’s useful when building from branches. Its behavior is controlled by the <code>$UseTimeStamp</code> 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 <code>multi-tinderbox</code>’ 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 <code>Cm1.0-M1.8.0</code> and adding a <code>Cm1.0.4</code> entry. Later, when the release is built, I’ll comment out <code>Cm1.0.4</code> and turn <code>Cm1.0-M1.8.0</code> back on. <code>multi-tinderbox</code> reloads its configuration when it receives a <code>SIGHUP</code>; 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 <code>multi-config.pl</code>.

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 <code>multi-tinderbox</code> to reload when the current build finishes:

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

When the release build begins, go to the [http://tinderbox.mozilla.org/Camino/ Camino tinderbox page], click “[http://tinderbox.mozilla.org/admintree.cgi?tree=Camino 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 your (my) mistakes|“fix-it”]] section above where I fixed <code>ad_blocking.css</code>, remembering that at this point, you’ve got both a <code>_MINIBRANCH</code> and <code>_RELEASE</code> 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 “[http://ftp.mozilla.org/pub/mozilla.org/camino/nightly/ nightly]” that tinderbox uploaded. If it seems reasonable, stage it and let people know. When possible, it’s nice to let the [http://caminol10n.mozdev.org/ 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 <code>/home/ftp/pub/camino/source/camino-1.0.4.tar.bz2</code>, and that directory has an <code>MD5SUMS</code> file as well. The multilingual release will go in
<code>/home/ftp/pub/camino/releases/Camino-1.0.4-MultiLang.dmg</code>, with a copy at <code>/home/ftp/pub/camino/releases/all/Camino-1.0.4.dmg</code>.

== Create a source release ==

We provide [http://ftp.mozilla.org/pub/mozilla.org/camino/source/ source tarballs] for major releases (not alphas, betas, or release candidates). Check out a fresh tree using anonymous CVS, so that the <code>CVS/Root</code> files are correct for people bootstrapping anonymous CVS workspaces. If the <code>.tar.bz2</code> 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|Stage it]].

== Have someone else set up Talkback reports ==

Ask Jay to set up [http://talkback-public.mozilla.org/reports/camino/ Talkback reports], at least until [http://code.google.com/p/google-breakpad/ Breakpad] is ready. Send him an e-mail with the relevant build information, like:

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

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

Releases:Branch Tag Build Release

2007-03-01T19:36:41Z

Mento: /* Create a source release */ Use explicit language

<big>How to (branch and tag and build and) release a new version of Camino</big>
 
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 [http://www.caminobrowser.org/releases/1.0.4.php Camino 1.0.4] ([http://www.mozilla.com/en-US/firefox/releases/1.5.0.10.html Gecko 1.8.0.10]). The base tag for this release was <code>FIREFOX_1_5_0_10_RELEASE</code>. This specifies the apex of the minibranch. For the 1.0.4 release, changes to that tag for Camino were made on a new <code>CAMINO_1_0_4_MINIBRANCH</code> branch, and the release tag was <code>CAMINO_1_0_4_RELEASE</code>. Camino branch and release tags follow this convention (<code>CAMINO_1_1_A2_MINIBRANCH</code>, <code>CAMINO_1_1_B_RELEASE</code>).

== 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 <code>-D</code> when checking out <code>client.mk</code>, and set <code>MOZ_CO_DATE</code> when making <code>client.mk</code>’s <code>checkout</code> 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 [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.

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. <code>client.mk</code> 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 <code>client.mk</code> if that’s all that’s changing. After branching, use <code>cvs update</code> to move the tag on the files you’ll be working on, so that changes will be committed to the right branch. The usage here branches everything rooted at the current working directory (<code>mozilla</code>). 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 <code>FIREFOX_1_5_0_10_RELEASE</code> tag didn’t include changes to two Camino files that had been made recently on the <code>MOZILLA_1_8_0_BRANCH</code> in anticipation of Camino 1.0.4. I realized this because the release notes were missing. I found the other file by querying [http://bonsai.mozilla.org/ 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 <code>cvs tag -B -F</code> to move the tag because <code>ad_blocking.css</code> had already been branched. <code>cvs tag -B -F</code> 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 <code>client.mk</code> apply to the minibranch ==

Now it’s possible to make changes to the working copy. First, update <code>client.mk</code> so that it will pull from the release tag (soon to be created). In this case, <code>sed</code> 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 <code>client.mk</code>. 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 [https://bugzilla.mozilla.org/buglist.cgi?status_whiteboard_type=substring&status_whiteboard=camino-1.0.3 querying Bugzilla for bugs with text like <code>camino-1.0.3</code>] in the status whiteboard field, by [http://bonsai.mozilla.org/cvsquery.cgi?branch=CAMINO_1_0_3_MINIBRANCH&date=all checking Bonsai for changes I made to the last release minibranch], or by asking [[User:Sardisson|Smokey]] or [[User:Admin|Sam]]. Those guys remember everything. These two things come from bugs [https://bugzilla.mozilla.org/show_bug.cgi?id=325765 325765] and [https://bugzilla.mozilla.org/show_bug.cgi?id=325964 325964]. When landing things on the minibranch, don’t forget to update the status whiteboard fields of the relevant bugs with text like <code>[camino-1.0.4]</code>.

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 [http://lxr.mozilla.org/mozilla/source/camino/docs/ReleaseChecklist.txt <code>camino/docs/ReleaseChecklist.txt</code>] 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 <code>MOZILLA_1_8_0_BRANCH</code> 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 <code>client.mk</code> 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, even NSPR and NSS.

cvs tag CAMINO_1_0_4_RELEASE

If someone pulls <code>client.mk</code> by the <code>CAMINO_1_0_4_RELEASE</code> tag, then they’ll get what they expect. Change the tags in <code>client.mk</code> 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 <code>$CVSROOT</code>, 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 <code>$BuildTag</code> in <code>tinder-config.pl</code> to make sure it corresponds to your chosen release tag (or branch). When building from a tag (instead of a branch), pull-by-timestamp (<code>cvs checkout -D</code>) must be turned off. It’s useful when building from branches. Its behavior is controlled by the <code>$UseTimeStamp</code> 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 <code>multi-tinderbox</code>’ 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 <code>Cm1.0-M1.8.0</code> and adding a <code>Cm1.0.4</code> entry. Later, when the release is built, I’ll comment out <code>Cm1.0.4</code> and turn <code>Cm1.0-M1.8.0</code> back on. <code>multi-tinderbox</code> reloads its configuration when it receives a <code>SIGHUP</code>; 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 <code>multi-config.pl</code>.

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 <code>multi-tinderbox</code> to reload when the current build finishes:

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

When the release build begins, go to the [http://tinderbox.mozilla.org/Camino/ Camino tinderbox page], click “[http://tinderbox.mozilla.org/admintree.cgi?tree=Camino 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 your (my) mistakes|“fix-it”]] section above where I fixed <code>ad_blocking.css</code>, remembering that at this point, you’ve got both a <code>_MINIBRANCH</code> and <code>_RELEASE</code> 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 “[http://ftp.mozilla.org/pub/mozilla.org/camino/nightly/ nightly]” that tinderbox uploaded. If it seems reasonable, stage it and let people know. When possible, it’s nice to let the [http://caminol10n.mozdev.org/ 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 <code>/home/ftp/pub/camino/source/camino-1.0.4.tar.bz2</code>, and that directory has an <code>MD5SUMS</code> file as well. The multilingual release will go in
<code>/home/ftp/pub/camino/releases/Camino-1.0.4-MultiLang.dmg</code>, with a copy at <code>/home/ftp/pub/camino/releases/all/Camino-1.0.4.dmg</code>.

== 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 <code>CVS/Root</code> files are correct for people bootstrapping anonymous CVS workspaces. If the <code>.tar.bz2</code> 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|Stage it]].

== Have someone else set up Talkback reports ==

Ask Jay to set up [http://talkback-public.mozilla.org/reports/camino/ Talkback reports], at least until [http://code.google.com/p/google-breakpad/ Breakpad] is ready. Send him an e-mail with the relevant build information, like:

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

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

Releases:Branch Tag Build Release

2007-03-01T19:34:47Z

Mento: /* Land other changes on the minibranch */ blankout

<big>How to (branch and tag and build and) release a new version of Camino</big>
 
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 [http://www.caminobrowser.org/releases/1.0.4.php Camino 1.0.4] ([http://www.mozilla.com/en-US/firefox/releases/1.5.0.10.html Gecko 1.8.0.10]). The base tag for this release was <code>FIREFOX_1_5_0_10_RELEASE</code>. This specifies the apex of the minibranch. For the 1.0.4 release, changes to that tag for Camino were made on a new <code>CAMINO_1_0_4_MINIBRANCH</code> branch, and the release tag was <code>CAMINO_1_0_4_RELEASE</code>. Camino branch and release tags follow this convention (<code>CAMINO_1_1_A2_MINIBRANCH</code>, <code>CAMINO_1_1_B_RELEASE</code>).

== 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 <code>-D</code> when checking out <code>client.mk</code>, and set <code>MOZ_CO_DATE</code> when making <code>client.mk</code>’s <code>checkout</code> 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 [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.

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. <code>client.mk</code> 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 <code>client.mk</code> if that’s all that’s changing. After branching, use <code>cvs update</code> to move the tag on the files you’ll be working on, so that changes will be committed to the right branch. The usage here branches everything rooted at the current working directory (<code>mozilla</code>). 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 <code>FIREFOX_1_5_0_10_RELEASE</code> tag didn’t include changes to two Camino files that had been made recently on the <code>MOZILLA_1_8_0_BRANCH</code> in anticipation of Camino 1.0.4. I realized this because the release notes were missing. I found the other file by querying [http://bonsai.mozilla.org/ 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 <code>cvs tag -B -F</code> to move the tag because <code>ad_blocking.css</code> had already been branched. <code>cvs tag -B -F</code> 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 <code>client.mk</code> apply to the minibranch ==

Now it’s possible to make changes to the working copy. First, update <code>client.mk</code> so that it will pull from the release tag (soon to be created). In this case, <code>sed</code> 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 <code>client.mk</code>. 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 [https://bugzilla.mozilla.org/buglist.cgi?status_whiteboard_type=substring&status_whiteboard=camino-1.0.3 querying Bugzilla for bugs with text like <code>camino-1.0.3</code>] in the status whiteboard field, by [http://bonsai.mozilla.org/cvsquery.cgi?branch=CAMINO_1_0_3_MINIBRANCH&date=all checking Bonsai for changes I made to the last release minibranch], or by asking [[User:Sardisson|Smokey]] or [[User:Admin|Sam]]. Those guys remember everything. These two things come from bugs [https://bugzilla.mozilla.org/show_bug.cgi?id=325765 325765] and [https://bugzilla.mozilla.org/show_bug.cgi?id=325964 325964]. When landing things on the minibranch, don’t forget to update the status whiteboard fields of the relevant bugs with text like <code>[camino-1.0.4]</code>.

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 [http://lxr.mozilla.org/mozilla/source/camino/docs/ReleaseChecklist.txt <code>camino/docs/ReleaseChecklist.txt</code>] 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 <code>MOZILLA_1_8_0_BRANCH</code> 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 <code>client.mk</code> 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, even NSPR and NSS.

cvs tag CAMINO_1_0_4_RELEASE

If someone pulls <code>client.mk</code> by the <code>CAMINO_1_0_4_RELEASE</code> tag, then they’ll get what they expect. Change the tags in <code>client.mk</code> 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 <code>$CVSROOT</code>, 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 <code>$BuildTag</code> in <code>tinder-config.pl</code> to make sure it corresponds to your chosen release tag (or branch). When building from a tag (instead of a branch), pull-by-timestamp (<code>cvs checkout -D</code>) must be turned off. It’s useful when building from branches. Its behavior is controlled by the <code>$UseTimeStamp</code> 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 <code>multi-tinderbox</code>’ 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 <code>Cm1.0-M1.8.0</code> and adding a <code>Cm1.0.4</code> entry. Later, when the release is built, I’ll comment out <code>Cm1.0.4</code> and turn <code>Cm1.0-M1.8.0</code> back on. <code>multi-tinderbox</code> reloads its configuration when it receives a <code>SIGHUP</code>; 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 <code>multi-config.pl</code>.

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 <code>multi-tinderbox</code> to reload when the current build finishes:

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

When the release build begins, go to the [http://tinderbox.mozilla.org/Camino/ Camino tinderbox page], click “[http://tinderbox.mozilla.org/admintree.cgi?tree=Camino 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 your (my) mistakes|“fix-it”]] section above where I fixed <code>ad_blocking.css</code>, remembering that at this point, you’ve got both a <code>_MINIBRANCH</code> and <code>_RELEASE</code> 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 “[http://ftp.mozilla.org/pub/mozilla.org/camino/nightly/ nightly]” that tinderbox uploaded. If it seems reasonable, stage it and let people know. When possible, it’s nice to let the [http://caminol10n.mozdev.org/ 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 <code>/home/ftp/pub/camino/source/camino-1.0.4.tar.bz2</code>, and that directory has an <code>MD5SUMS</code> file as well. The multilingual release will go in
<code>/home/ftp/pub/camino/releases/Camino-1.0.4-MultiLang.dmg</code>, with a copy at <code>/home/ftp/pub/camino/releases/all/Camino-1.0.4.dmg</code>.

== 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 <code>CVS/Root</code> files are correct for people bootstrapping anonymous CVS workspaces. If the <code>.tar.bz2</code> 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 co -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|Stage it]].

== Have someone else set up Talkback reports ==

Ask Jay to set up [http://talkback-public.mozilla.org/reports/camino/ Talkback reports], at least until [http://code.google.com/p/google-breakpad/ Breakpad] is ready. Send him an e-mail with the relevant build information, like:

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

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

Releases:Branch Tag Build Release

2007-03-01T19:32:41Z

Mento: /* Make Tinderbox build it */ Make more disparaging comments about myself

<big>How to (branch and tag and build and) release a new version of Camino</big>
 
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 [http://www.caminobrowser.org/releases/1.0.4.php Camino 1.0.4] ([http://www.mozilla.com/en-US/firefox/releases/1.5.0.10.html Gecko 1.8.0.10]). The base tag for this release was <code>FIREFOX_1_5_0_10_RELEASE</code>. This specifies the apex of the minibranch. For the 1.0.4 release, changes to that tag for Camino were made on a new <code>CAMINO_1_0_4_MINIBRANCH</code> branch, and the release tag was <code>CAMINO_1_0_4_RELEASE</code>. Camino branch and release tags follow this convention (<code>CAMINO_1_1_A2_MINIBRANCH</code>, <code>CAMINO_1_1_B_RELEASE</code>).

== 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 <code>-D</code> when checking out <code>client.mk</code>, and set <code>MOZ_CO_DATE</code> when making <code>client.mk</code>’s <code>checkout</code> 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 [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.

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. <code>client.mk</code> 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 <code>client.mk</code> if that’s all that’s changing. After branching, use <code>cvs update</code> to move the tag on the files you’ll be working on, so that changes will be committed to the right branch. The usage here branches everything rooted at the current working directory (<code>mozilla</code>). 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 <code>FIREFOX_1_5_0_10_RELEASE</code> tag didn’t include changes to two Camino files that had been made recently on the <code>MOZILLA_1_8_0_BRANCH</code> in anticipation of Camino 1.0.4. I realized this because the release notes were missing. I found the other file by querying [http://bonsai.mozilla.org/ 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 <code>cvs tag -B -F</code> to move the tag because <code>ad_blocking.css</code> had already been branched. <code>cvs tag -B -F</code> 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 <code>client.mk</code> apply to the minibranch ==

Now it’s possible to make changes to the working copy. First, update <code>client.mk</code> so that it will pull from the release tag (soon to be created). In this case, <code>sed</code> 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 <code>client.mk</code>. 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 [https://bugzilla.mozilla.org/buglist.cgi?status_whiteboard_type=substring&status_whiteboard=camino-1.0.3 querying Bugzilla for bugs with text like <code>camino-1.0.3</code>] in the status whiteboard field, by [http://bonsai.mozilla.org/cvsquery.cgi?branch=CAMINO_1_0_3_MINIBRANCH&date=all checking Bonsai for changes I made to the last release minibranch], or by asking [[User:Sardisson|Smokey]] or [[User:Admin|Sam]]. Those guys remember everything. These two things come from bugs [https://bugzilla.mozilla.org/show_bug.cgi?id=325765 325765] and [https://bugzilla.mozilla.org/show_bug.cgi?id=325964 325964]. When landing things on the minibranch, don’t forget to update the status whiteboard fields of the relevant bugs with text like <code>[camino-1.0.4]</code>.

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 [http://lxr.mozilla.org/mozilla/source/camino/docs/ReleaseChecklist.txt <code>camino/docs/ReleaseChecklist.txt</code>] 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 <code>MOZILLA_1_8_0_BRANCH</code> 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 <code>client.mk</code> 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, even NSPR and NSS.

cvs tag CAMINO_1_0_4_RELEASE

If someone pulls <code>client.mk</code> by the <code>CAMINO_1_0_4_RELEASE</code> tag, then they’ll get what they expect. Change the tags in <code>client.mk</code> 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 <code>$CVSROOT</code>, 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 <code>$BuildTag</code> in <code>tinder-config.pl</code> to make sure it corresponds to your chosen release tag (or branch). When building from a tag (instead of a branch), pull-by-timestamp (<code>cvs checkout -D</code>) must be turned off. It’s useful when building from branches. Its behavior is controlled by the <code>$UseTimeStamp</code> 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 <code>multi-tinderbox</code>’ 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 <code>Cm1.0-M1.8.0</code> and adding a <code>Cm1.0.4</code> entry. Later, when the release is built, I’ll comment out <code>Cm1.0.4</code> and turn <code>Cm1.0-M1.8.0</code> back on. <code>multi-tinderbox</code> reloads its configuration when it receives a <code>SIGHUP</code>; 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 <code>multi-config.pl</code>.

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 <code>multi-tinderbox</code> to reload when the current build finishes:

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

When the release build begins, go to the [http://tinderbox.mozilla.org/Camino/ Camino tinderbox page], click “[http://tinderbox.mozilla.org/admintree.cgi?tree=Camino 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 your (my) mistakes|“fix-it”]] section above where I fixed <code>ad_blocking.css</code>, remembering that at this point, you’ve got both a <code>_MINIBRANCH</code> and <code>_RELEASE</code> 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 “[http://ftp.mozilla.org/pub/mozilla.org/camino/nightly/ nightly]” that tinderbox uploaded. If it seems reasonable, stage it and let people know. When possible, it’s nice to let the [http://caminol10n.mozdev.org/ 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 <code>/home/ftp/pub/camino/source/camino-1.0.4.tar.bz2</code>, and that directory has an <code>MD5SUMS</code> file as well. The multilingual release will go in
<code>/home/ftp/pub/camino/releases/Camino-1.0.4-MultiLang.dmg</code>, with a copy at <code>/home/ftp/pub/camino/releases/all/Camino-1.0.4.dmg</code>.

== 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 <code>CVS/Root</code> files are correct for people bootstrapping anonymous CVS workspaces. If the <code>.tar.bz2</code> 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 co -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|Stage it]].

== Have someone else set up Talkback reports ==

Ask Jay to set up [http://talkback-public.mozilla.org/reports/camino/ Talkback reports], at least until [http://code.google.com/p/google-breakpad/ Breakpad] is ready. Send him an e-mail with the relevant build information, like:

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

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

Releases:Branch Tag Build Release

2007-03-01T19:27:55Z

Mento: /* Have someone else set up Talkback reports */ linko

<big>How to (branch and tag and build and) release a new version of Camino</big>
 
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 [http://www.caminobrowser.org/releases/1.0.4.php Camino 1.0.4] ([http://www.mozilla.com/en-US/firefox/releases/1.5.0.10.html Gecko 1.8.0.10]). The base tag for this release was <code>FIREFOX_1_5_0_10_RELEASE</code>. This specifies the apex of the minibranch. For the 1.0.4 release, changes to that tag for Camino were made on a new <code>CAMINO_1_0_4_MINIBRANCH</code> branch, and the release tag was <code>CAMINO_1_0_4_RELEASE</code>. Camino branch and release tags follow this convention (<code>CAMINO_1_1_A2_MINIBRANCH</code>, <code>CAMINO_1_1_B_RELEASE</code>).

== 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 <code>-D</code> when checking out <code>client.mk</code>, and set <code>MOZ_CO_DATE</code> when making <code>client.mk</code>’s <code>checkout</code> 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 [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.

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. <code>client.mk</code> 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 <code>client.mk</code> if that’s all that’s changing. After branching, use <code>cvs update</code> to move the tag on the files you’ll be working on, so that changes will be committed to the right branch. The usage here branches everything rooted at the current working directory (<code>mozilla</code>). 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 <code>FIREFOX_1_5_0_10_RELEASE</code> tag didn’t include changes to two Camino files that had been made recently on the <code>MOZILLA_1_8_0_BRANCH</code> in anticipation of Camino 1.0.4. I realized this because the release notes were missing. I found the other file by querying [http://bonsai.mozilla.org/ 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 <code>cvs tag -B -F</code> to move the tag because <code>ad_blocking.css</code> had already been branched. <code>cvs tag -B -F</code> 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 <code>client.mk</code> apply to the minibranch ==

Now it’s possible to make changes to the working copy. First, update <code>client.mk</code> so that it will pull from the release tag (soon to be created). In this case, <code>sed</code> 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 <code>client.mk</code>. 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 [https://bugzilla.mozilla.org/buglist.cgi?status_whiteboard_type=substring&status_whiteboard=camino-1.0.3 querying Bugzilla for bugs with text like <code>camino-1.0.3</code>] in the status whiteboard field, by [http://bonsai.mozilla.org/cvsquery.cgi?branch=CAMINO_1_0_3_MINIBRANCH&date=all checking Bonsai for changes I made to the last release minibranch], or by asking [[User:Sardisson|Smokey]] or [[User:Admin|Sam]]. Those guys remember everything. These two things come from bugs [https://bugzilla.mozilla.org/show_bug.cgi?id=325765 325765] and [https://bugzilla.mozilla.org/show_bug.cgi?id=325964 325964]. When landing things on the minibranch, don’t forget to update the status whiteboard fields of the relevant bugs with text like <code>[camino-1.0.4]</code>.

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 [http://lxr.mozilla.org/mozilla/source/camino/docs/ReleaseChecklist.txt <code>camino/docs/ReleaseChecklist.txt</code>] 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 <code>MOZILLA_1_8_0_BRANCH</code> 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 <code>client.mk</code> 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, even NSPR and NSS.

cvs tag CAMINO_1_0_4_RELEASE

If someone pulls <code>client.mk</code> by the <code>CAMINO_1_0_4_RELEASE</code> tag, then they’ll get what they expect. Change the tags in <code>client.mk</code> 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 <code>$CVSROOT</code>, 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 <code>$BuildTag</code> in <code>tinder-config.pl</code> to make sure it corresponds to your chosen release tag (or branch). When building from a tag (instead of a branch), pull-by-timestamp (<code>cvs checkout -D</code>) must be turned off. It’s useful when building from branches. Its behavior is controlled by the <code>$UseTimeStamp</code> 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 <code>multi-tinderbox</code>’ 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 <code>Cm1.0-M1.8.0</code> and adding a <code>Cm1.0.4</code> entry. Later, when the release is built, I’ll comment out <code>Cm1.0.4</code> and turn <code>Cm1.0-M1.8.0</code> back on. <code>multi-tinderbox</code> reloads its configuration when it receives a <code>SIGHUP</code>; 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 <code>multi-config.pl</code>.

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 <code>multi-tinderbox</code> to reload when the current build finishes:

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

When the release build begins, go to the [http://tinderbox.mozilla.org/Camino/ Camino tinderbox page], click “[http://tinderbox.mozilla.org/admintree.cgi?tree=Camino 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 section above where I fixed <code>ad_blocking.css</code>, remembering that at this point, you’ve got both a <code>_MINIBRANCH</code> and <code>_RELEASE</code> 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 “[http://ftp.mozilla.org/pub/mozilla.org/camino/nightly/ nightly]” that tinderbox uploaded. If it seems reasonable, stage it and let people know. When possible, it’s nice to let the [http://caminol10n.mozdev.org/ 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 <code>/home/ftp/pub/camino/source/camino-1.0.4.tar.bz2</code>, and that directory has an <code>MD5SUMS</code> file as well. The multilingual release will go in
<code>/home/ftp/pub/camino/releases/Camino-1.0.4-MultiLang.dmg</code>, with a copy at <code>/home/ftp/pub/camino/releases/all/Camino-1.0.4.dmg</code>.

== 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 <code>CVS/Root</code> files are correct for people bootstrapping anonymous CVS workspaces. If the <code>.tar.bz2</code> 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 co -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|Stage it]].

== Have someone else set up Talkback reports ==

Ask Jay to set up [http://talkback-public.mozilla.org/reports/camino/ Talkback reports], at least until [http://code.google.com/p/google-breakpad/ Breakpad] is ready. Send him an e-mail with the relevant build information, like:

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

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

Releases:Branch Tag Build Release

2007-03-01T19:25:45Z

Mento: /* Create a source release */ Reduce ugly

<big>How to (branch and tag and build and) release a new version of Camino</big>
 
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 [http://www.caminobrowser.org/releases/1.0.4.php Camino 1.0.4] ([http://www.mozilla.com/en-US/firefox/releases/1.5.0.10.html Gecko 1.8.0.10]). The base tag for this release was <code>FIREFOX_1_5_0_10_RELEASE</code>. This specifies the apex of the minibranch. For the 1.0.4 release, changes to that tag for Camino were made on a new <code>CAMINO_1_0_4_MINIBRANCH</code> branch, and the release tag was <code>CAMINO_1_0_4_RELEASE</code>. Camino branch and release tags follow this convention (<code>CAMINO_1_1_A2_MINIBRANCH</code>, <code>CAMINO_1_1_B_RELEASE</code>).

== 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 <code>-D</code> when checking out <code>client.mk</code>, and set <code>MOZ_CO_DATE</code> when making <code>client.mk</code>’s <code>checkout</code> 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 [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.

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. <code>client.mk</code> 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 <code>client.mk</code> if that’s all that’s changing. After branching, use <code>cvs update</code> to move the tag on the files you’ll be working on, so that changes will be committed to the right branch. The usage here branches everything rooted at the current working directory (<code>mozilla</code>). 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 <code>FIREFOX_1_5_0_10_RELEASE</code> tag didn’t include changes to two Camino files that had been made recently on the <code>MOZILLA_1_8_0_BRANCH</code> in anticipation of Camino 1.0.4. I realized this because the release notes were missing. I found the other file by querying [http://bonsai.mozilla.org/ 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 <code>cvs tag -B -F</code> to move the tag because <code>ad_blocking.css</code> had already been branched. <code>cvs tag -B -F</code> 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 <code>client.mk</code> apply to the minibranch ==

Now it’s possible to make changes to the working copy. First, update <code>client.mk</code> so that it will pull from the release tag (soon to be created). In this case, <code>sed</code> 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 <code>client.mk</code>. 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 [https://bugzilla.mozilla.org/buglist.cgi?status_whiteboard_type=substring&status_whiteboard=camino-1.0.3 querying Bugzilla for bugs with text like <code>camino-1.0.3</code>] in the status whiteboard field, by [http://bonsai.mozilla.org/cvsquery.cgi?branch=CAMINO_1_0_3_MINIBRANCH&date=all checking Bonsai for changes I made to the last release minibranch], or by asking [[User:Sardisson|Smokey]] or [[User:Admin|Sam]]. Those guys remember everything. These two things come from bugs [https://bugzilla.mozilla.org/show_bug.cgi?id=325765 325765] and [https://bugzilla.mozilla.org/show_bug.cgi?id=325964 325964]. When landing things on the minibranch, don’t forget to update the status whiteboard fields of the relevant bugs with text like <code>[camino-1.0.4]</code>.

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 [http://lxr.mozilla.org/mozilla/source/camino/docs/ReleaseChecklist.txt <code>camino/docs/ReleaseChecklist.txt</code>] 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 <code>MOZILLA_1_8_0_BRANCH</code> 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 <code>client.mk</code> 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, even NSPR and NSS.

cvs tag CAMINO_1_0_4_RELEASE

If someone pulls <code>client.mk</code> by the <code>CAMINO_1_0_4_RELEASE</code> tag, then they’ll get what they expect. Change the tags in <code>client.mk</code> 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 <code>$CVSROOT</code>, 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 <code>$BuildTag</code> in <code>tinder-config.pl</code> to make sure it corresponds to your chosen release tag (or branch). When building from a tag (instead of a branch), pull-by-timestamp (<code>cvs checkout -D</code>) must be turned off. It’s useful when building from branches. Its behavior is controlled by the <code>$UseTimeStamp</code> 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 <code>multi-tinderbox</code>’ 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 <code>Cm1.0-M1.8.0</code> and adding a <code>Cm1.0.4</code> entry. Later, when the release is built, I’ll comment out <code>Cm1.0.4</code> and turn <code>Cm1.0-M1.8.0</code> back on. <code>multi-tinderbox</code> reloads its configuration when it receives a <code>SIGHUP</code>; 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 <code>multi-config.pl</code>.

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 <code>multi-tinderbox</code> to reload when the current build finishes:

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

When the release build begins, go to the [http://tinderbox.mozilla.org/Camino/ Camino tinderbox page], click “[http://tinderbox.mozilla.org/admintree.cgi?tree=Camino 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 section above where I fixed <code>ad_blocking.css</code>, remembering that at this point, you’ve got both a <code>_MINIBRANCH</code> and <code>_RELEASE</code> 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 “[http://ftp.mozilla.org/pub/mozilla.org/camino/nightly/ nightly]” that tinderbox uploaded. If it seems reasonable, stage it and let people know. When possible, it’s nice to let the [http://caminol10n.mozdev.org/ 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 <code>/home/ftp/pub/camino/source/camino-1.0.4.tar.bz2</code>, and that directory has an <code>MD5SUMS</code> file as well. The multilingual release will go in
<code>/home/ftp/pub/camino/releases/Camino-1.0.4-MultiLang.dmg</code>, with a copy at <code>/home/ftp/pub/camino/releases/all/Camino-1.0.4.dmg</code>.

== 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 <code>CVS/Root</code> files are correct for people bootstrapping anonymous CVS workspaces. If the <code>.tar.bz2</code> 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 co -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|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 find this information from the <code>Contents/MacOS/components/talkback/master.ini</code> file from <code>Camino.app</code> in the release you’ve built.

Releases:Home Page

2007-03-01T19:23:48Z

Mento: /* General Documents */ Add BTBR

== Camino 1.0 ==
[[Releases:1.0:Notes]] are the final release notes for 1.0.
* The complete (full changelog) release notes for 1.0 are here: [[Releases:1.0:Notes Complete]]

[[Releases:1.0:Translation_Status]] gives an overview of where the l10n team was with translating 1.0.

[[Releases:1.0:Press_Coverage]] lists various press outlets which noted our 1.0 release.

* The release promotion information page for 1.0 final are to be found here: [[Releases:1.0:Promotion]] ([[Releases:1.0:Announcement Translations|Translations]])

== Camino 1.0.1 ==
[[Releases:1.0.1:Links]] gives various useful links for 1.0.1 bug triage and targeting.

[[Releases:1.0.1:Notes]] houses the current release notes for 1.0.1.

== Camino 1.0.2 ==
[[Releases:1.0.2:Links]] gives various useful links for 1.0.2 bug triage and targeting.

[[Releases:1.0.2:Notes]] houses the current release notes for 1.0.2.

== Camino 1.0.3 ==
[[Releases:1.0.3:Links]] gives various useful links for 1.0.3 bug triage and targeting.

[[Releases:1.0.3:Notes]] houses the current release notes for 1.0.3.

== Camino 1.0.4 ==
[[Releases:1.0.4:Links]] gives various useful links for 1.0.4 bug triage and targeting.

[[Releases:1.0.4:Notes]] houses the current release notes for 1.0.4.

== Camino 1.0.5 ==
[[Releases:1.0.5:Links]] gives various useful links for 1.0.5 bug triage and targeting.

[[Releases:1.0.5:Notes]] houses the current release notes for 1.0.5.

== Camino 1.1 ==
* [[Releases:1.1a1:Notes]] are the release notes for 1.1a1
* [[Releases:1.1a2:Notes]] are the release notes for 1.1a2
* [[Releases:1.1b:Notes]] are the release notes for 1.1b
* The running release notes for 1.1 are found here: [[Releases:Release Notes 1.1|Release Notes 1.1]]
* cb.o/support elements that will need changing are here: [[Website:Documentation Changes for 1.1|Documentation Changes for 1.1]]

== General Documents ==
* [[Releases:Website Checklist]] lists the various things that need to be completed on the website for each release.
* [[Releases:Branch Tag Build Release]], the how-to-mento handbook.

Releases:Branch Tag Build Release

2007-03-01T19:22:15Z

Mento: Just because I wrote this up does NOT mean it's OK for a bus to hit me

<big>How to (branch and tag and build and) release a new version of Camino</big>
 
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 [http://www.caminobrowser.org/releases/1.0.4.php Camino 1.0.4] ([http://www.mozilla.com/en-US/firefox/releases/1.5.0.10.html Gecko 1.8.0.10]). The base tag for this release was <code>FIREFOX_1_5_0_10_RELEASE</code>. This specifies the apex of the minibranch. For the 1.0.4 release, changes to that tag for Camino were made on a new <code>CAMINO_1_0_4_MINIBRANCH</code> branch, and the release tag was <code>CAMINO_1_0_4_RELEASE</code>. Camino branch and release tags follow this convention (<code>CAMINO_1_1_A2_MINIBRANCH</code>, <code>CAMINO_1_1_B_RELEASE</code>).

== 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 <code>-D</code> when checking out <code>client.mk</code>, and set <code>MOZ_CO_DATE</code> when making <code>client.mk</code>’s <code>checkout</code> 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 [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.

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. <code>client.mk</code> 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 <code>client.mk</code> if that’s all that’s changing. After branching, use <code>cvs update</code> to move the tag on the files you’ll be working on, so that changes will be committed to the right branch. The usage here branches everything rooted at the current working directory (<code>mozilla</code>). 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 <code>FIREFOX_1_5_0_10_RELEASE</code> tag didn’t include changes to two Camino files that had been made recently on the <code>MOZILLA_1_8_0_BRANCH</code> in anticipation of Camino 1.0.4. I realized this because the release notes were missing. I found the other file by querying [http://bonsai.mozilla.org/ 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 <code>cvs tag -B -F</code> to move the tag because <code>ad_blocking.css</code> had already been branched. <code>cvs tag -B -F</code> 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 <code>client.mk</code> apply to the minibranch ==

Now it’s possible to make changes to the working copy. First, update <code>client.mk</code> so that it will pull from the release tag (soon to be created). In this case, <code>sed</code> 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 <code>client.mk</code>. 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 [https://bugzilla.mozilla.org/buglist.cgi?status_whiteboard_type=substring&status_whiteboard=camino-1.0.3 querying Bugzilla for bugs with text like <code>camino-1.0.3</code>] in the status whiteboard field, by [http://bonsai.mozilla.org/cvsquery.cgi?branch=CAMINO_1_0_3_MINIBRANCH&date=all checking Bonsai for changes I made to the last release minibranch], or by asking [[User:Sardisson|Smokey]] or [[User:Admin|Sam]]. Those guys remember everything. These two things come from bugs [https://bugzilla.mozilla.org/show_bug.cgi?id=325765 325765] and [https://bugzilla.mozilla.org/show_bug.cgi?id=325964 325964]. When landing things on the minibranch, don’t forget to update the status whiteboard fields of the relevant bugs with text like <code>[camino-1.0.4]</code>.

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 [http://lxr.mozilla.org/mozilla/source/camino/docs/ReleaseChecklist.txt <code>camino/docs/ReleaseChecklist.txt</code>] 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 <code>MOZILLA_1_8_0_BRANCH</code> 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 <code>client.mk</code> 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, even NSPR and NSS.

cvs tag CAMINO_1_0_4_RELEASE

If someone pulls <code>client.mk</code> by the <code>CAMINO_1_0_4_RELEASE</code> tag, then they’ll get what they expect. Change the tags in <code>client.mk</code> 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 <code>$CVSROOT</code>, 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 <code>$BuildTag</code> in <code>tinder-config.pl</code> to make sure it corresponds to your chosen release tag (or branch). When building from a tag (instead of a branch), pull-by-timestamp (<code>cvs checkout -D</code>) must be turned off. It’s useful when building from branches. Its behavior is controlled by the <code>$UseTimeStamp</code> 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 <code>multi-tinderbox</code>’ 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 <code>Cm1.0-M1.8.0</code> and adding a <code>Cm1.0.4</code> entry. Later, when the release is built, I’ll comment out <code>Cm1.0.4</code> and turn <code>Cm1.0-M1.8.0</code> back on. <code>multi-tinderbox</code> reloads its configuration when it receives a <code>SIGHUP</code>; 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 <code>multi-config.pl</code>.

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 <code>multi-tinderbox</code> to reload when the current build finishes:

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

When the release build begins, go to the [http://tinderbox.mozilla.org/Camino/ Camino tinderbox page], click “[http://tinderbox.mozilla.org/admintree.cgi?tree=Camino 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 section above where I fixed <code>ad_blocking.css</code>, remembering that at this point, you’ve got both a <code>_MINIBRANCH</code> and <code>_RELEASE</code> 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 “[http://ftp.mozilla.org/pub/mozilla.org/camino/nightly/ nightly]” that tinderbox uploaded. If it seems reasonable, stage it and let people know. When possible, it’s nice to let the [http://caminol10n.mozdev.org/ 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 <code>/home/ftp/pub/camino/source/camino-1.0.4.tar.bz2</code>, and that directory has an <code>MD5SUMS</code> file as well. The multilingual release will go in
<code>/home/ftp/pub/camino/releases/Camino-1.0.4-MultiLang.dmg</code>, with a copy at <code>/home/ftp/pub/camino/releases/all/Camino-1.0.4.dmg</code>.

== 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 <code>CVS/Root</code> files are correct for people bootstrapping anonymous CVS workspaces. If the <code>.tar.bz2</code> 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 co -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 find this information from the <code>Contents/MacOS/components/talkback/master.ini</code> file from <code>Camino.app</code> in the release you’ve built.

QA:Hardware Configurations

2006-07-05T21:40:50Z

Mento: /* Project Leads */

==Who to bug for OS/hardware combinations==
When you need patch testing or triage help....

===QA/Developers===

*[[User:Froodian|froodian]] - iBook G4 1.33 GHz, 1.25 GB, running OS X 10.4 (latest update)
*[[User:clawson|clawson]] - PowerBook G4 1.5 GHz, 2 GB, 10.4 (latest update). Kensington Expert Mouse with Kensington drivers.
*Torben has Macs that run 10.2.8 and 10.3.9
*smorgan has an iMac Core Duo
*[[User:Wevah|Wevah]] has a MacBook Pro 2.0 GHz, 2 GB, running 10.4.7
*[[User:hwaara|hwaara]] has an iMac G5, 1.9 GHz, 1 GB, running latest OS X 10.4. Uses a Mighty Mouse.
*[[User:kreeger|kreeger]] has an iBook G4 Latest 10.4, access to a 10.3.9 Mac Mini, uses various mice, and has a couple of windows XP/Linux machines.
*[[User:japser|japser]]
*[[User:Ludo|Ludo]]
*BruceD
*[[User:delliott|delliott]] has a MacBook Core Duo 1.83, 512MB, 10.4
*[[User:sardisson|sardisson]] - PowerBook G4 1.33 GHz, 1.5 GB, running 10.3.9
*: can do simple project changes in lieu of pink's or mento's Xcode 2.0 Macs
*[[User:Admin|ss]] - iBook G4 1.2 GHz, 1.25 GB, running 10.4 and Intel Mac mini Core Duo running 10.4.7
*[[User:Peeja|peeja]] - (for now) iBook G3 900MHz, 384MB, 10.3.9

====Project Leads====
''They all have some manner of Intel Mac, plus others''
*[[User:pinkerton|pinkerton]] - Has hardware so sweet that he won't tell us, has both PPC and Intel machines, and uses a Microsoft wheel mouse
*[[User:mento|mento]] has like seven Macs or something and can run releases as old as 10.1.
*[[User:smfr|smfr]]

===Community===
found on [irc://irc.mozilla.org/#camino #camino]
*[[User:ChrisCasciano|pnhChris]] runs 10.3.9
* davedit is on 10.4
* [[User:krmathis|krmathis]] is also on 10.4

Releases:1.0.2:Links

2006-06-02T20:55:44Z

Mento: (f) you

Camino 1.0.2 will come from a new minibranch based on Gecko 1.8.0.4.

==Pre-branching checkins==
The following Camino-only bugs need to be landed before we mini-branch:

* {{bug|336497}} - Writing Spotlight metadata files for Bonjour bookmarks generates thousands of files (also fixes {{bug|335163}})

:ref: [https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=RESOLVED&bug_status=VERIFIED&cmdtype=doit&order=Last+Changed&field0-0-0=flagtypes.name&type0-0-0=equals&value0-0-0=camino1.0.2%2B camino1.0.2+ bugs] - if FIXED, either already landed on '''1.8.0.4''' ('''''not''' on CAMINO_1_0_1_MINIBRANCH in all cases''), or ML only
:landed: mm

==Land on the mini-branch==
The following bugs need to land on the mini-branch:

* {{Bug|321366}} - Crash [@PR_Close].[@nsDiskCacheStreamIO::Flush()]
:landed: mm
* {{Bug|325964}} - MathML missing fonts dialogue contatins extra space character (Camino-only)
:landed: mm
* ''Potentially'' aka [https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=RESOLVED&cmdtype=doit&order=Last+Changed&field0-0-0=flagtypes.name&type0-0-0=equals&value0-0-0=camino1.0.2%3F camino1.0.2?]
** {{bug|324501}} - Search field input box renders with unnecessary border
:landed: mm

:ref: [camino-1.0] or [camino-1.0.1] not fixed/verified 1.8.0.1/1.8.0.2/1.8.0.3/1.8.0.4 [https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=anywordssubstr&status_whiteboard=%5Bcamino-1.0%5D+%5Bcamino-1.0.1%5D&keywords_type=nowords&keywords=fixed1.8.0.2+verified1.8.0.2+fixed1.8.0.3+verified1.8.0.3+fixed1.8.0.4+verified1.8.0.4&emailassigned_to1=1&emailtype1=exact&email1=&emailassigned_to2=1&emailreporter2=1&emailqa_contact2=1&emailtype2=exact&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0= query] plus the camino1.0.2? query above.

==Land somewhere==

* {{bug|336846}} - Relnotes for 1.0.2
*: (needs sr/make sure everything they claim is included actually lands)
:landed: mm

==Also==

* Do the release checklist
:landed: mm
* Cache version should be 1.8 for Camino ({{bug|325765}})
:landed: mm

Releases:1.0.2:Notes

2006-06-02T18:26:36Z

Mento: /* Changes since Camino 1.0 */ rectile

==About Camino 1.0.2==
Camino 1.0.2 is a security and stability update for Camino 1.0.x; all users are recommended to upgrade.

==Changes since Camino 1.0==
The following changes and improvements have been made since the Camino 1.0 release.

'''In Camino 1.0.2, we have made the following changes and improvements since version 1.0.1:'''
* Fixed several critical security issues, including those fixed in version 1.8.0.4 of the Mozilla Gecko rendering engine.
* Fixed an issue in Camino 1.0.1 where proxy auto-config (PAC) files were ignored.
* Fixed an issue where Camino’s bookmark metadata could not be added to the list of locations Spotlight is prevented from searching.
* Fixed an issue where using Camino on a network with many Bonjour hosts could significantly degrade performance.
* Fixed an issue where Camino would ignore the “Link from other application” tabbed browsing preference in certain cases.
* Fixed an issue where Camino displayed some search fields on Apple.com incorrectly.

'''In Camino 1.0.1, we have made the following changes and improvements since version 1.0:'''
* Fixed several critical security issues, including those fixed in version 1.8.0.3 of the Mozilla Gecko rendering engine.
* Upgraded the bundled [http://javaplugin.sf.net Java Embedding Plugin] to version 0.9.5+d.
* Improved ad-blocking, especially of German ads.
* Enabled the opening of local SVG files.
* Fixed an issue where Camino on Intel-based Macs was unable to read Keychain entries stored by Camino on PowerPC-based Macs.

==Highlights of Camino 1.0==
Below is a list of the major changes in Camino 1.0. A full list is available on our website.

* General
** Camino is now a universal binary, allowing it to run natively on both PowerPC- and Intel-based Macs.
** Moving backward and forward through history is now “blazingly fast”.
** The “Fill Form” menu item and toolbar button use your personal Address Book card to automatically fill out forms on the current web page.
** Ad-blocking is now built-in, but turned off by default.
** The “Camino” menu now has a “Reset Camino…” menu item, which will erase your browsing history, empty the cache, clear downloads, clear all cookies, and clear all site permissions.
** The “Camino” menu now has an “Empty Cache…” menu item.
** An optional warning is shown when closing windows with multiple tabs or when quitting with multiple windows open.
** Camino now has certificate-management capabilities.
*** It is now possible to trust a new Certificate Authority.
*** The Certificates window, accessible from the Security preference pane, shows the set of certificates included with Camino and any newly-downloaded certificates.
** The about:config preference editor is now mostly functional.

* Bookmarks and History
** Camino now includes live searching of bookmarks and history.
** It is now possible to sort bookmarks alphabetically.
** The “Go” menu now displays global history, showing sites you visited in any window, ordered by date.
** Spotlight will now index Camino bookmarks.
** Camino now displays custom icons for Bookmarks, History, and local files.

* Tabbed browsing
** The tab bar has been rewritten from scratch.
*** Tabs now appear on the left of the window, instead of in the center.
*** Windows can now contain more than 16 tabs, and tabs which do not fit on the tab bar appear in an overflow menu.
*** The tab bar can remain visible when a single tab is open.
** Double-clicking on empty space in the tab bar creates a new tab.
** Command-enter in the location bar or search field will now open the page or search results in a new tab or new window (instead of the current tab or window).

* Downloading
** Camino now saves the list of downloads between sessions.
** Downloads can be paused and resumed.

* Web Content
** Camino now has support for “document.designMode” (inline HTML editing, also known as Midas), SVG, the <canvas> tag, and MathML.
** Web page access keys now work in Camino.
** Camino now uses version 1.8 of Mozilla’s Gecko rendering engine, which contains thousands of bug fixes.
** Images are drawn and tiled using Core Graphics for improved performance.
** The pop-up blocker can now stop pop-ups generated by plugins (like Flash).

* Plugins
** Camino now ships with the Java Embedding Plugin (http://javaplugin.sourceforge.net/), which provides support for Java 1.4. On Mac OS X 10.4, Java 5.0 is also supported.

* Preferences
** Camino now supports third-party preference panes. These can be installed by placing them into the <tt>~/Library/Application Support/Camino/PreferencePanes</tt> folder.
** There is a new preference to make animated images play only once.
** The cookie and cookie exception lists are now searchable.
** Camino now uses the language information in the International pane of the System Preferences to send data on what languages you understand to websites. This can be overridden by the “camino.accept_languages” hidden preference.
** Proxy Auto-Config (PAC) settings are now read from the entries in the Network pane of the System Preferences.

==Known Issues==
* The recently released RealPlayer 10.1.0 (v400) causes Camino to crash when viewing any Real content. Real has released RealPlayer 10.1.0 (v412) to address this issue. Users should re-download RealPlayer and verify (using the application’s About window) that it is version 412 before launching Camino.

* Microsoft’s Windows Media Player (WMP) plugin causes major rendering issues in Camino. Since Microsoft has discontinued WMP on Mac OS X, Camino no longer supports the use of the WMP plugin; instead, all users should download the free Flip4Mac (F4M) plugin, version 2.0.2 or higher, from http://www.flip4mac.com/. Version 2.0.2 causes pages containing WMP content to become white when scrolled in Camino; there is currently no ETA for a fixed version of the F4M plugin.

* Although typing performance has improved in Camino 1.0, typing in form fields can be slow when Flash or animated images are present. Turning off animations can improve performance in some cases.

* Shockwave Director content displays at the wrong location in the browser window when hardware rendering is enabled. Switch the plugin to software rendering to solve this.

* Due to a bug in Mac OS X 10.2.x and 10.3.x, Norwegian users of Camino will need to manually set their 'accept-language' string. To set the accept-language string, add the string <tt>user_pref("camino.accept_languages", "nb,nn,no,en");</tt> to your [http://www.caminobrowser.org/support/hiddenprefs/#createUserjs user.js file], where the languages are listed in the order in which you’d prefer them if a server can send content in multiple languages. (In this example, you want Bokmål first, then Nynorsk, then generic Norwegian, then English if none of the other three languages are available.) You may now launch Camino. Apple fixed this bug in Mac OS X 10.4, so no work-arounds are necessary.

* Camino erroneously claims that the default Japanese and Traditional Chinese fonts are “missing” when they are actually installed; this is due to a mismatch between Carbon and Cocoa font names. Changing these fonts using the Camino user interface will result in incorrect fonts being chosen and will cause some characters to fail to display. Users should either keep the default fonts or change the font preferences manually, ensuring the Carbon versions of the font names are used.

* Some users have experienced an issue where downloading files will cause Camino to hang when Quicksilver is installed. Users can work around this issue by either disabling indexing of the Desktop in Quicksilver or by setting the default download location to somewhere other than the Desktop in Camino’s Downloads preferences.