Release Branching Process

Procedure

branches/x.y would be the branch for all x.y.z releases
when a release is frozen, we spin off a branch with that exact name, as in branches/x.y.z, where z starts at zero and increments by one.
at that time branches/x.y is immediately updated to version x.y.(z+1)-SNAPSHOT
We cut releases from the frozen branch
When a release passes final tck testing and final vote, the frozen branch is moved to tags

Updating the poms after making a new branch

Once a new branch is created you will generally need to manage the version number in the poms. The following Perl scripts will assist in that task. It could use some polishing but given the relatively infrequent use.

Pom Version Changer

perl -i.orig -pe '
$done = 0 if /<?xml/;
$inParent = 1 if not $done and /<parent>/;
s,oldVersion</version>,newVersion</version>, if $inParent and not $done;
$done = $inParent = 1 if /<\/parent>/;
' $(find GeronimoDirectory -name pom.xml | grep -v "GeronimoDirectory/pom.xml")

Remember to properly escape periods in the oldVersion. For instance, to change 1.1.1-SNAPSHOT to 1.1.1 you would have

Example

perl -i.orig -pe '
$done = 0 if /<?xml/;
$inParent = 1 if not $done and /<parent>/;
s,1\.1\.1-SNAPSHOT</version>,1.1.1</version>, if $inParent and not $done;
$done = $inParent = 1 if /<\/parent>/;
' $(find GeronimoDirectory -name pom.xml | grep -v "GeronimoDirectory/pom.xml")

Rational

We create a branch at freeze time for the following reasons:

it takes at least one week from freeze to ship due to voting, tck testing and potential repeats of that process (re-cut, re-certify, re-vote). There is no reason why work on x.y.z+1 needs to be delayed - only 52 weeks a year.
stronger guarantee no one is updating the branch once frozen
less likely that people and ci systems (continuum) will checkout and build pre-release versions of x.y.z (not x.y.z-SNAPSHOT) which would need to be removed manually and may accidentally be distributed.
it is currently very difficult to roll version numbers forward, entries here and there are often missed. Far better to have branches/x.y have a few straggling old x.y.z-SNAPSHOT versions than a few overlooked x.y.z final numbers that needed to go back to SNAPSHOT - they never leave SNAPSHOT and need to be reverted back later if that process happens in the frozen branch.

Steps

Download and install the Gnu Privacy Guard (GPG) from http://www.gnupg.org. Read the documentation on that site and create a key. Have the key signed and verified by others. Submit your public key to http://pgp.mit.edu/. This is a one time process.

Create a "staging" profile in your .m2/settings.xml

<profile>
    <id>staging</id>
    <properties>
        <!-- deploy.altRepository>prasad::default::scp://people.apache.org/x1/home/prasad/public_html/2.0-M1-rc1</deploy.altRepository -->
        <deploy.altRepository>prasad::default::file://c:\cygwin\home\prasad\releases</deploy.altRepository>
        <gpg.passphrase>Your GPG Passphrase</gpg.passphrase>
    </properties>
</profile>

Copy (or move as per situation, for eg specs) the trunk to branches using the following command.
```
svn mv SRC-URL DEST-URL -m "Reason for this commit".
```
Checkout or update this branches tree on your machine.

Update the <scm> urls in the pom.xml to point to the final url in tags. Eg:

<scm>
     <connection>scm:svn:http://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-servlet_2.5_spec-1.1</connection>
     <developerConnection>scm:svn:https://svn.apache.org/repos/asf/geronimo/repos/asf/geronimo/specs/tags/geronimo-servlet_2.5_spec-1.1</developerConnection>
     <url>http://svn.apache.org/viewvc/geronimo/repos/asf/geronimo/specs/tags/geronimo-servlet_2.5_spec-1.1</url>
</scm>

Build the new branches tree that will soon be released using the following command.
```
mvn -Pdefault,staging deploy
```
Go the temporary staging directory specified by deploy.altRepository element in the staging profile of your settings.xml. Delete all *.asc.* files under this directory tree. Tar the staging directory using the command
```
find . -name *.asc.* | xargs rm -f
tar -zcvf release.tar.gz releases
```
Copy the tar ball to a publicly accessible location. Put it for a vote. In the vote notice, please include the precise names and versions being voted on (e.g. geronimo-javamail_1.4_spec-1.1) and the svn urls to the current source and where the tag will be created.
After it has been approved, untar the tar ball into the appropriate maven structure on people.apache.org under the directory /www/people.apache.org/repo/m2-ibiblio-rsync-repository. A cron job will rsync this with ibiblio and release it into the wild.
```
gunzip foo.tar.gz
tar -xvf foo.tar
```
Ensure that the files you copy to the rsynch directoory have 0775 dir permission and a 0664 file permisison set on them

Move the branches to tags using the following command.

svn mv SRC-URL DEST-URL -m "Reason for this commit".

Notice

The process in this document was voted on by the Geronimo community. Please formally propose all changes to dev@geronimo.apache.org.

See:

http://marc.theaimsgroup.com/?l=geronimo-dev&m=115094116905426&w=4