Jetty6 Release Process
Currently the release procedure for Jetty6 is a mostly manual operation:
- Verify that there are no blocking issues on the lists or in JIRA.
- Update VERSION.txt with the release number and date and commit to trunk.
- Create tags in jetty and jetty-contrib repositories with a copy from trunk (or the branch used as a basis for the release):
- Checkout tag:
- Edit svn:externals to include contrib tag:
- Update the poms and other files to change 6.1-SNAPSHOT to x.y.z:
greps should be done to make sure that all 6.1-SNAPSHOT references have been updated.
The diff in the script will sometimes need to be updated. Recursive
- Commit the changes to the tag:
- build the release
#build additional bundles and jars:
NOTE: you will need the rpmbuild utility installed in order to build the rpm module. NOTE: please also use jdk1.4 to build the jboss sar, as this will use jsp-2.0, which some versions of jboss seem to need in order to run it's web console correctly.
#build the release bundles:
This builds a binary and source zip bundle in the parent directory.
- Tell somebody else about the tag and ask them to check it out and test it!
- Test the tag yourself in situ (if you need to fix anything you will need to completely clean and go back to first build step).
- Test the built bundle
- Test the RPM
- Wait a day for other feedback from other testers
- Create directories in distribution directories and copy artifacts to codehaus (webdav to https://dav.codehaus.org/dist/jetty/ ) and mortbay (scp to email@example.com:/home/ftp/pub/jetty-x.y.z/). The artifacts to upload are:
- ONLY WHEN YOU ARE REALLY REALLY REALLY REALLY REALLY SURE EVERYTHING IS REALLY REALLY REALLY OK, then push the maven artifacts:
- Tell everybody: blogs, lists, etc.
- Wait for the bug reports to come in
Jetty7 Release Process
The jetty7 release process leverages many elements of maven2 including the maven-release-plugin for a more automated release experience. The jetty7 release process is currently composed of a couple of different phases which are explained below.
The first portion of the release is to release the portion of the build located in the jetty/trunk svn. The -DautoVersionSubmodules=true portion will skip the versioning of every single artifact in the build which is quite tedious as generally you share the same version of all artifacts in a release. This step will convert the pom.xml files to the released version, build the project, commit the release pom.xml files to trunk, tag the release, convert the pom.xml files back to SNAPSHOT development versions and then commit those new development poms, effectively resetting trunk to the next development cycle. The convention we follow is to reset the development versions back to 7.0-SNAPSHOT which is a question asked during the release:prepare step.
The next phase of the release is to process the jetty-contrib trunk. The critical difference here is that we edit and commit the jetty-contrib-parent pom.xml file, setting the
property to the version we released in the earlier phase. This is the property that all contrib artifacts that make use of jetty trunk artifacts should use in their <version/> sections. Here we activate the all-modules profile which picks up the contrib artifacts that are to be released so they can be processed via the release plugin. In the future we expect that contrib modules will be able to have different release cycles but currently anything being released is kept in lockstep with the jetty release version wise.
Next we need to checkout the jetty tag that we made in the first phase and adjust the svn:externals to reflect the tagged jetty-contrib version. We also set the pom portion of the svn:externals to the released version of the administrative parent pom. You can get this version by looking for the number of the parent of the root pom in the jetty checkout. If it is '2' then the pom should be set to the tag of jetty-parent-2. This file is not used in the build, but is set for posterity mainly. Then we smoke the contrib and pom directories and update the tagged versions of them. Once the checkout is completely from tagged scm source we run a build from the top level to populate the root project structure with necessary files. We generate the assembly which is currently not an automated portion of the release so we adjust the pom.xml accordingly and then deploy.