SeaMonkey:Release Process: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
(fill in "Moving An Existing Release Tag" section)
(change to reflect some additions I made for 1.1.5 release)
Line 13: Line 13:
  CVS_LOGIN=kairo%kairo.at
  CVS_LOGIN=kairo%kairo.at
  CVS_REPOS="-d :ext:$CVS_LOGIN@cvs.mozilla.org:/cvsroot"
  CVS_REPOS="-d :ext:$CVS_LOGIN@cvs.mozilla.org:/cvsroot"
  PULLTAG=FIREFOX_2_0_0_8_RELEASE
  PULLTAG=GECKO181_20071004_RELBRANCH
  #PULLTAG=MOZILLA_1_8_BRANCH
  #PULLTAG=MOZILLA_1_8_BRANCH
  MINIBRANCH=SEAMONKEY_1_1_5_MINIBRANCH
  MINIBRANCH=SEAMONKEY_1_1_5_MINIBRANCH
  RELEASETAG=SEAMONKEY_1_1_5_RELEASE
  RELEASETAG=SEAMONKEY_1_1_5_RELEASE
  #CO_OPTS=MOZ_CO_DATE="2007-01-09 13:00:00"
  CO_OPTS=MOZ_CO_DATE=\"`date +"%F %T"`\"
  CO_OPTS=<br>
  #CO_OPTS=<br>
  echo "cvs $CVS_REPOS checkout -r $PULLTAG $CO_OPTS mozilla/client.mk"
  echo "cvs $CVS_REPOS checkout -r $PULLTAG $CO_OPTS mozilla/client.mk"
  echo "cd mozilla"
  echo "cd mozilla"
  echo "make -f client.mk checkout $CO_OPTS MOZ_CO_PROJECT=suite"
  echo "make -f client.mk checkout $CO_OPTS MOZ_CO_PROJECT=suite"
Line 28: Line 28:
  echo "rm ../client.mk.orig"
  echo "rm ../client.mk.orig"
  echo "cvs $CVS_REPOS commit -r $MINIBRANCH -m 'edit tags to pull from $RELEASETAG' client.mk"
  echo "cvs $CVS_REPOS commit -r $MINIBRANCH -m 'edit tags to pull from $RELEASETAG' client.mk"
echo "mv xpfe/bootstrap/version.txt ../version.txt.orig"
echo "sed 's/pre//' ../version.txt.orig > xpfe/bootstrap/version.txt"
echo "rm ../version.txt.orig"
echo "mv xpfe/bootstrap/module.ver ../module.ver.orig"
echo "sed 's/pre//' ../module.ver.orig > xpfe/bootstrap/module.ver"
echo "rm ../module.ver.orig"
echo "cvs $CVS_REPOS commit -r $PULLTAG -m 'remove \"pre\" postfix from SeaMonkey version on release branch' xpfe/bootstrap/module.ver xpfe/bootstrap/version.txt"
  echo "cvs $CVS_REPOS tag -F $RELEASETAG client.mk"
  echo "cvs $CVS_REPOS tag -F $RELEASETAG client.mk"
  echo "cvs $CVS_REPOS tag $RELEASETAG"
  echo "cvs $CVS_REPOS tag $RELEASETAG"


This outputs a list of commands to run for the tagging process, which I execute step by step, checking that the right thing is actually done. SeaMonkey usually pulls from a Firefox release tag, so we have a well-defined state to pull. If we don't pull a release tag but a branch tag, I also set the CO_OPTS variable to use an exact date so that the tree is also well-defined.
This outputs a list of commands to run for the tagging process, which I execute step by step, checking that the right thing is actually done. SeaMonkey usually pulls from a not-much-changing Gecko release branch near to a Firefox release tag, so we usually have a well-defined state to pull, but to make sure when pulling from that branch, I also set the CO_OPTS variable to use an exact date (automatically to the time of pulling in that script) so that the tree is 100% well-defined.


The commands pull a client.mk and use it to pull a complete suite (SeaMonkey) source checkout. We're only tagging files that are part of this checkout. For versions where building own builds with the old calendar extension was still supported, we also included calendar in that pull and in our tag as well as our source tarballs (see later), but nowadays the suite pull is enough.
The commands pull a client.mk and use it to pull a complete suite (SeaMonkey) source checkout. We're only tagging files that are part of this checkout. For versions where building own builds with the old calendar extension was still supported, we also included calendar in that pull and in our tag as well as our source tarballs (see later), but nowadays the suite pull is enough.


The first commit to client.mk does not show up anywhere actually, so the message is useless, but I remember that CVS didn't correctly realize that it had the state of that minibranch and might choke afterwards. The mv/sed/rm stuff is to make the client.mk pull our new SeaMonkey release tag, the second commit to client.mk will actually be recorded in the file's cvs history and should tell what that tag change actually was.
The first commit to client.mk does not show up anywhere actually, so the message is useless, but I remember that CVS didn't correctly realize that it had the state of that minibranch and might choke afterwards. The mv/sed/rm stuff is to make the client.mk pull our new SeaMonkey release tag, the second commit to client.mk will actually be recorded in the file's cvs history and should tell what that tag change actually was.
We do similar things to module.ver and version.txt in the next steps to remove the "pre" postfix on the SeaMonkey version number, just that we can commit them directly to the Gecko release branch, as those are SeaMonkey-specific files anyways.


The actual tagging is done with the last two commands, first the new tag is forced on the client.mk file, then the rest of the tree is tagged.
The actual tagging is done with the last two commands, first the new tag is forced on the client.mk file, then the rest of the tree is tagged.

Revision as of 15:31, 8 October 2007

Note: This page is currently a work in progress, I'll try to fill in any missing item when we're doing the next SeaMonkey release (which should be 1.1.5 then).

This page is a collection of things currently done to do SeaMonkey 1.1.x releases, so that the process is documented in some way.

Tagging

Creating A New Release Tag

The first step for doing the actual release is to create a tag in CVS. I usually go into an empty directory on my local (Linux) machine and run the following bash script first (after adjusting the pull and release tag variables at the beginning of it):

#!/bin/bash
CVS_LOGIN=kairo%kairo.at CVS_REPOS="-d :ext:$CVS_LOGIN@cvs.mozilla.org:/cvsroot" PULLTAG=GECKO181_20071004_RELBRANCH #PULLTAG=MOZILLA_1_8_BRANCH MINIBRANCH=SEAMONKEY_1_1_5_MINIBRANCH RELEASETAG=SEAMONKEY_1_1_5_RELEASE CO_OPTS=MOZ_CO_DATE=\"`date +"%F %T"`\" #CO_OPTS=
echo "cvs $CVS_REPOS checkout -r $PULLTAG $CO_OPTS mozilla/client.mk" echo "cd mozilla" echo "make -f client.mk checkout $CO_OPTS MOZ_CO_PROJECT=suite" echo "cvs $CVS_REPOS tag -b $MINIBRANCH client.mk" echo "cvs $CVS_REPOS commit -r $MINIBRANCH -m 'initial minibranch commit' client.mk" echo "mv client.mk ../client.mk.orig" echo "sed 's/$PULLTAG/$RELEASETAG/' ../client.mk.orig > client.mk" echo "rm ../client.mk.orig" echo "cvs $CVS_REPOS commit -r $MINIBRANCH -m 'edit tags to pull from $RELEASETAG' client.mk" echo "mv xpfe/bootstrap/version.txt ../version.txt.orig" echo "sed 's/pre//' ../version.txt.orig > xpfe/bootstrap/version.txt" echo "rm ../version.txt.orig" echo "mv xpfe/bootstrap/module.ver ../module.ver.orig" echo "sed 's/pre//' ../module.ver.orig > xpfe/bootstrap/module.ver" echo "rm ../module.ver.orig" echo "cvs $CVS_REPOS commit -r $PULLTAG -m 'remove \"pre\" postfix from SeaMonkey version on release branch' xpfe/bootstrap/module.ver xpfe/bootstrap/version.txt" echo "cvs $CVS_REPOS tag -F $RELEASETAG client.mk" echo "cvs $CVS_REPOS tag $RELEASETAG"

This outputs a list of commands to run for the tagging process, which I execute step by step, checking that the right thing is actually done. SeaMonkey usually pulls from a not-much-changing Gecko release branch near to a Firefox release tag, so we usually have a well-defined state to pull, but to make sure when pulling from that branch, I also set the CO_OPTS variable to use an exact date (automatically to the time of pulling in that script) so that the tree is 100% well-defined.

The commands pull a client.mk and use it to pull a complete suite (SeaMonkey) source checkout. We're only tagging files that are part of this checkout. For versions where building own builds with the old calendar extension was still supported, we also included calendar in that pull and in our tag as well as our source tarballs (see later), but nowadays the suite pull is enough.

The first commit to client.mk does not show up anywhere actually, so the message is useless, but I remember that CVS didn't correctly realize that it had the state of that minibranch and might choke afterwards. The mv/sed/rm stuff is to make the client.mk pull our new SeaMonkey release tag, the second commit to client.mk will actually be recorded in the file's cvs history and should tell what that tag change actually was.

We do similar things to module.ver and version.txt in the next steps to remove the "pre" postfix on the SeaMonkey version number, just that we can commit them directly to the Gecko release branch, as those are SeaMonkey-specific files anyways.

The actual tagging is done with the last two commands, first the new tag is forced on the client.mk file, then the rest of the tree is tagged.

Usually, the next step from here is to create a first set of candidate builds.

Moving An Existing Release Tag

For later candidates, the tag is moved on any files that have changed compared to the older candidate.

To do this, first I update the files to the respective versions, most of the time this will be something like

cvs -d :ext:kairo%kairo.at@cvs.mozilla.org:/cvsroot checkout -r GECKO181_20071004_RELBRANCH MOZ_CO_DATE="2007-10-08 17:19:35" mozilla/updated/file1.cpp mozilla/updated/file2.h

Then, move the tag like this:

cvs -d :ext:kairo%kairo.at@cvs.mozilla.org:/cvsroot tag -F SEAMONKEY_1_1_5_RELEASE mozilla/updated/file1.cpp mozilla/updated/file2.h

Creating Builds

TODO

Doing The Actual Release

TODO