This page last changed on Sep 28, 2006 by tcarlson.
The following process should be followed when a release is made. please pay attentiona to each step to insure a successful release.
- Check that the Mule Roadmap has resolved all issues scheduled for this release. If not, resolve them, or schedule remaining issues to a future version.
- Send e-mail to the development mailing list warning people that you are about to cut a release.
- Make sure a branch exists for this release line (e.g., https://svn.codehaus.org/mule/branches/mule-1.4/ could be used to release 1.4-M2, 1.4-rc3, 1.4.2, etc.) It is bad practice to release from the trunk, if a branch does not yet exist for this release line, create one as follows:
svn mkdir -m "New branch for 1.4 release line" https:svn copy https:
- If you are not already working on the branch, either check it out or switch to it as follows:
svn co https:svn switch https:
- Unlike m1, in m2 you need to update the version in every single pom.xml file in the entire project. Fortunately, there's a script which makes this simple. Assuming you've just checked out the project, the following command will replace the version "1.4-SNAPSHOT" in all poms with "1.4-rc2"
mule/buildtools/scripts/update_poms.sh mule 1.4-SNAPSHOT 1.4-rc2
- Make sure there are no more SNAPSHOT versions left in the project:
grep SNAPSHOT `find . -name pom.xml`
The script above should have replaced the SNAPSHOT version for Mule itself, but you may have some SNAPSHOT versions as library or plugin dependencies. These need to be replaced by releases or at least timestamped versions, otherwise the release is not guaranteed to be reproducible.
- Perform a clean, complete build of the entire project, making sure no modules get excluded due to profiles. Run all unit/integration/QA tests. Build all distributions including javadocs and sources. Unzip the generated full distribution, run the examples. The following script may be helpful for this step:
mule/buildtools/scripts/build.sh
- When you are convinced that the release has been built correctly, deploy/upload all artifacts to the public repository.
 | Uploading
The jars are uploaded using m2's deploy goal:
mvn -DperformRelease=true deploy
The distributions could eventually be uploaded by the deploy goal as well, but for now can be easily uploaded by hand using copy/paste in Windows Explorer, which handles WebDAV rather nicely. |
- Commit your changes to Subversion.
- Tag the release as follows:
svn mkdir -m "Tag release" https:svn copy https:
- Set the version in the POMs back to a SNAPSHOT for continuing development/nightly builds on this release line:
mule/buildtools/scripts/update_poms.sh mule 1.4-rc2 1.4-SNAPSHOT
Commit these changes to Subversion.
- Mark the version as released in JIRA
- Create more upcoming versions in JIRA if necessary.
- Update the Mule Blog and announce the release.
- Send e-mail to the user and developer mailing list announcing the release, with a link to the blog entry.
- If this is a major release, also send announcements to TheServerside.com, FreshMeat.net and JavaLobby.org.
- Give yourself a pat on the back and a beer!
|