Jetty Release Procedures
Currently the release procedure for Jetty 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:
#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 firstname.lastname@example.org:/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