Overview

This info is for Cocoon committers who need to distribute a new release of Cocoon or any subproject of Cocoon.

Naming Conventions

The name of each downloadable archive should be named after the following regular expression:

        cocoon(-SUBPROJECT)?-VERSION(-VARIANT)?-(src|bin).(zip|tar.gz) 
      

Where:

So, all our archives shall be called something like: cocoon-2.0.4-jdk14-bin.tar.gz or cocoon-2.1m1-src.zip and so on...

Subprojects apply to the same rule, except that of course they add their project name before the version information. For example for Lenya, the name should be along the lines of cocoon-lenya-1.0-bin.tar.gz.

The Release Process

This is a step-by-step procedure that covers the last eight days before the actual release date.

Code Freeze

Prior to the release day, a code freeze should be announced approx. eight days in advance.

Test Phase

During the code freeze the whole Cocoon community is invited to test test distribution, find and fix bugs and update the documentation. if desired an invitation to the community to help in polishing the release can be send out to the mailing lists.

Voting the release tarball

Three days before the actual release date, a release tarball is generated and put on a publically reachable location. Now a vote is started for the next 72h if this tarball can be used as the final release. This tarball only differs in the version information.

During this period, no commits should alter the repository.

If the vote is accepted, the release process is started. If the vote fails, it has to be decided what to do next.

Starting the Release Process

Send a simple mail to the developer list. This is in order to ensure that noone will check in during the release process. If someone checks in during the building, testing and tagging, the release process has to be started at the beginning again. Otherwise the release version is not the one tagged in Subversion.

Get the Version

Check-out a fresh copy from Subversion on a unix platform (this is important, do not use windows!)

Set Correct Version Information

Change the version information in src/java/org/apache/cocoon/cocoon.properties by removing -dev and eventually add new release information like m1, b1 etc. If this release is a final version, change the released.version info to the new version as well.

And also change the version accordingly in forrest.properties. But don't check-in this yet!

Exclude unstable blocks from the default build

Edit the blocks.properties file and exclude all unstable blocks. Since it's a release they should not get compiled by default.

Build the Distrubtion

Make sure that you make a clean build and that you are really not using windows:

# ./build.sh clean-dist
# ./build.sh dist
        

Test the distribution

Unarchive the build distribution and test it. These tests should include different platforms (windows and unix) and different JDKs (1.3 and 1.4). Testing includes building Cocoon from the release version and trying out the samples. Please also run 'build test'.

Decide what to do next

If any problem occurs during building and/or testing, you have to decide whether this is a blocker and has to be fixed or if this problem can be ignored. If it is a blocker, the problem must be fixed and after that you have to restart at the beginning. This decision is a from case to case decision and it's the release manager who decides if it's a blocker or not :)

Continuing the Release Process

Now check-in the changed version from the first step and tag the release in Subversion. Currently three files should have been changed in the last steps:

Use RELEASE_{VERSION} as the tag for tagging the release, like RELEASE_2_1_5.

Starting the Next Version

Change the version in src/java/org/apache/cocoon/cocoon.properties by increasing the version information and adding "-dev" at the end, for example 2.1m3-dev.

Change the version in forrest.properties to the same value.

Update the blocks.properties and enable all blocks that you have disabled for the release.

Change status.xml by adding the release with proper version and date and start a new release section with placeholders. Add a dummy action here.

Check-in all these changes.

Signing the Release

Therefore you have to put your public key in the KEYS file (before the starting the release process!). In addition create a md5 file for the distribution

Bugtracking

Enter the new version into bugzilla, so users can file entries against it.

Uploading the Release

The only (ONLY) place where distributions shall reside is inside the /www/www.apache.org/dist/cocoon on www.apache.org.

This directory contains three subdirectories:

Upload the release (including signatures and MD5 files) to www.apache.org and put it under /www/www.apache.org/dist/cocoon into the correct directories (SOURCES and BINARIES). Make sure that you set the permissions correctly. It's important to give the group write access!

Add/change the links from the cocoon directory to the new version in the sources/binaries directory. Update the README.html and the HEADER.html. For more information see below.

In the future, when other subprojects of Cocoon will start putting out their own releases, new directories will be created under the top level directory, with the same structure. For example the final directory will look something like:

www/www.apache.org/dist/cocoon/
|
+- BINARIES/
|  |
|  +- cocoon-2.0.3-bin.tar.gz
|  |
|  \- cocoon-2.0.4-bin.tar.gz
|
+- SOURCES/
|  |
|  +- cocoon-2.0.3-src.tar.gz
|  |
|  +- cocoon-2.0.4-src.tar.gz
|  |
|  +- cocoon-2.1m1-src.tar.gz
|  |
|  \- cocoon-2.1m2-src.tar.gz
|
+- OLD/
|  | 
|  +- cocoon-1.8.1.tar.gz
|  |
|  \- cocoon-1.8.2.tar.gz
|
+- cocoon-latest-bin.tar.gz -> BINARIES/cocoon-2.0.4-bin.tar.gz
|
+- cocoon-latest-src.tar.gz -> SOURCES/cocoon-2.0.4-src.tar.gz
|
+- lenya/
|  |
|  +- BINARIES/
|  |  |
|  |  \- cocoon-lenya-1.0-bin.tar.gz
|  |
|  +- SOURCES/
|  |  |
|  |  \- cocoon-lenya-1.0-src.tar.gz
|  |
|  +- cocoon-lenya-latest-bin.tar.gz -> BINARIES/cocoon-lenya-1.0-bin.tar.gz
|  |
|  \- cocoon-lenya-latest-src.tar.gz -> SOURCES/cocoon-lenya-1.0-src.tar.gz
| 
\- license.txt
        

Announcement

Announce to the developer list that the release process is finished and end a possible code freeze.

Take a break...

Now wait for 24h so the mirror sites can pick up the new version. You can have a look at mirror info page to see the status of the mirrors.

Update mirror page

Change the mirror.html in the cocoon-site module as well and update this single file on the website. For more information see below.

Create the announcement mail

Currently this is hand-typed (or copied) - we have to reinstall the announcement target. Send this email to wherever appropriate. Currently it goes to (dev at cocoon.apache.org, users at cocoon.apache.org, general at xml.apache.org and announcements at xml.apache.org)

Remember that the locations to mention in any announcements when downloads are involved is http://cocoon.apache.org/mirror.cgi. So that people will actually __use__ the mirrors and not peg the Foundation's bandwidth (which is quite expensive).

Register final version

Enter a final version (no betas or milestones) into Freshmeat.

Update the site docs

Update the site docs as described here.

Enter new version

Update the latest version on the Wiki.

Publishing and linking

Once the distribution ball is rolled following the naming convention and copied in the appropriate directory as outlined above, make sure that the following links are present (and only those links) in the root directory for the project/subproject:

- A link to the latest released stable version for each tar/zipball: for example, if the latest release is 2.0.4, and this release includes 3 different balls, 2 for binaries and 1 for sources, the following links must be done:

  # cd /www/www.apache.org/dist/cocoon
  # ln -s BINARIES/cocoon-2.0.4-vm14-bin.tar.gz cocoon-2.0.4-vm14-bin.tar.gz
  # ln -s BINARIES/cocoon-2.0.4-vm14-bin.zip cocoon-2.0.4-vm14-bin.zip
  # ln -s BINARIES/cocoon-2.0.4-bin.tar.gz cocoon-2.0.4-bin.tar.gz
  # ln -s BINARIES/cocoon-2.0.4-bin.zip cocoon-2.0.4-bin.zip
  # ln -s SOURCES/cocoon-2.0.4-src.tar.gz cocoon-2.0.4-src.tar.gz
  # ln -s SOURCES/cocoon-2.0.4-src.zip cocoon-2.0.4-src.zip
      

- A link to the latest milestone version for each tar/zipball (if present): for example, if 2.1m1 publishes only one ball, the source one:

  # cd /www/www.apache.org/dist/cocoon
  # ln -s SOURCES/cocoon-2.1-src.tar.gz cocoon-2.1-src.tar.gz
  # ln -s SOURCES/cocoon-2.1-src.zip cocoon-2.1-src.zip
      

- A link to the LATEST STABLE DOWNLOADABLE with the "version" string replaced by the "latest" keyword. If the above example of 2.0.4 is still valid:

  # cd /www/www.apache.org/dist/cocoon
  # ln -s BINARIES/ccoon-2.0.4-vm14-bin.tar.gz cocoon-latest-vm14-bin.tar.gz
  # ln -s BINARIES/cocoon-2.0.4-vm14-bin.zip cocoon-latest-vm14-bin.zip
  # ln -s BINARIES/cocoon-2.0.4-bin.tar.gz cocoon-latest-bin.tar.gz
  # ln -s BINARIES/cocoon-2.0.4-bin.zip cocoon-latest-bin.zip
  # ln -s SOURCES/cocoon-2.0.4-src.tar.gz cocoon-latest-src.tar.gz
  # ln -s SOURCES/cocoon-2.0.4-src.zip cocoon-latest-src.zip
      

Make sure to change the "latest version" strings and URLs in the README.html and HEADER.html files in the /www/www.apache.org/dist/cocoon/ directory and the mirror.html file in the /www/cocoon.apache.org/ directory.