...
After you create the release branch, you need to set its version and update CHANGES.txt to be consistent with it being a release version. Here is the basic checklist.
- Update the build.xml - change the version number to the the planned release version ("XXXX")
- Update all the maven pom.xml files - formerly, we used "mvn versions:set -DnewVersion=XXXX", but that now seems to be unreliable, so see below
- Edit CHANGES.txt to mark the release (convert "XXXX-dev" to "Release XXXX")
- Check in these changes to the release branch
Since this process has been error-prone and is no longer even remotely automatic (due to the unreliability of mvn versions:set), I've written scripts that do the work. Specifically:
- create_release_branch.py <release_branch_version> <new_trunk_version>
- update_release_branch.py <release_branch_major_version> <new_branch_version>
The first script makes a copy of trunk and to "branches/release-<version>-branch". It modifies build.xml, CHANGES.txt, and all the pom.xml files on both branch and trunk. The second script operates on an existing release branch to mark a bug fix release. It updates build.xml, CHANGES.txt, and all the pom.xml files on "branches/release-<major-version>-branch". Both scripts can be found in svn under https://svn.apache.org/repos/asf/manifoldcf/release-scripts .
Before releasing
Before you cut a release, it's always a good idea to run all the tests you can on the software. Also necessary is a "rat" run, which detects unknown or incorrect licenses on source files. See the complete checklist below.
...
Release Process 