...
1 | Make sure the #One time setup steps have been performed | |||||||
---|---|---|---|---|---|---|---|---|
2 | If releasing from the trunk, first make a branch from which to make the release. Releasing from a branch will allow any cosmetic changes that need to be made for the release to be approved to be done without preventing other more distruptive advances in the trunk from potentially causing problems with the release. A branch can be made by running: | |||||||
|
| |||||||
3 | Update the POMs to remove "-SNAPSHOT" from the version. If you have perl installed, you can easily do it with a single command: | |||||||
|
| |||||||
34 | Commit the POM changes | |||||||
|
| |||||||
45 | Perform the build with documentation and install it in the local repository (this step is required because there is a bug in Maven's javadoc generation aggregated between multiple modules): | |||||||
|
| |||||||
|
| |||||||
56 | Verify the signatures: | |||||||
|
| |||||||
67 | Now actually build the javadocs and perform the deploy upload: | |||||||
|
| |||||||
78 | Tag the view branch with the release number: | |||||||
|
| |||||||
89 | Update the pom.xml files to the subsequent version with the -SNAPSHOT suffix: | |||||||
|
| |||||||
910 | Commit the POM changes | |||||||
|
| |||||||
1011 | Start a vote for the release on the open-jpa-dev@incubator.apache.org mailing list. For an example of the mail, see this archived vote | |||||||
1112 | If the vote is successful after 3 days, mail general@incubator.apache.org starting a vote for authorization to release | |||||||
1213 | Once that vote is successful, update the http://cwiki.apache.org/openjpa/downloads.html page with information about the download |
...
Code Block | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
#!/bin/sh -pve # Author: Marc Prud'hommeaux <mprudhom@apache.org> # # USE AT YOUR OWN RISK! # # Performs the release steps described at: # # http://cwiki.apache.org/openjpa/releasing-openjpa.html # # It will do the following: # # 1. Check out a fresh version of openjpa from the branch # 2. Update the openjpa pom.xml files to have the new version # 3. Commit the pom.xml changes # 4. Make the release files # 5. Verify the signature # 6. Test the examples in the release # 7. Perform the deploy # 8. Tag the view using "svn copy" # 9. Update the pom.xml versions to be the next version # 10. Commit the new pom.xml files BASEDIR=/tmp/openjpa-staging/ RELEASEDIR=${BASEDIR}/openjpa EXAMPLESDIR=${BASEDIR}/examples rm -rf ${BASEDIR} || echo Staging directory already deleted # OLDVERSION=0.9.6-incubating-SNAPSHOT # RELEASEVERSION=0.9.6-incubating # NEXTVERSION=0.9.7-incubating-SNAPSHOT OLDVERSION=${1} RELEASEVERSION=${2} NEXTVERSION=${3} shift; shift; shift; EXTRAARGS=${@} # example usage: # openjpa.mkrelease 0.9.6-incubating-SNAPSHOT 0.9.6-incubating 0.9.7-incubating-SNAPSHOT # openjpa.mkrelease 0.9.6-incubating-SNAPSHOT 0.9.6-incubating 0.9.7-incubating-SNAPSHOT \ # -Dopenjpa.release.keyAlias=somegpgkeyalias@somedomain.org test ! -z ${NEXTVERSIONRELEASEVERSION} || echo "Usage: ${0} OLDVERSION RELEASEVERSION NEXTVERSION" test ! -z ${NEXTVERSIONRELEASEVERSION} # svn co https://svn.apache.org/repos/asf/incubator/openjpa/trunk/ ${RELEASEDIR} # Check out from the branch (note that a branch with the same name as the release version needs to exist)... SVNBASE="https://svn.apache.org/repos/asf/incubator/openjpa" TRUNK="${SVNBASE}/trunk" BRANCH="${SVNBASE}/branches/${RELEASEVERSION}" TAG="${SVNBASE}/tags/${RELEASEVERSION}" svn co ${BRANCH} ${RELEASEDIR} || (echo "$0: Branch does not exist. You can create it from the trunk with: svn copy ${TRUNK} ${BRANCH}" && false) cd ${RELEASEDIR} grep "<version>${OLDVERSION}</version>" pom.xml || echo "ERROR: version is not the expected version (${OLDVERSION})" grep "<version>${OLDVERSION}</version>" pom.xml perl -pi -e "s;<version>${OLDVERSION}</version>;<version>${RELEASEVERSION}</version>;g" pom.xml */pom.xml svn commit -m "Updated to version ${RELEASEVERSION}" # Pre-build: need to do this to get around bugs in aggregate javadocs, as # well as making a signature we can test mvn clean install -Pdocbook-profile,sign-release "${EXTRAARGS}" # Verify the signatures gpg --multifile --verify openjpa-project/target/assembly/*.asc # Test the examples to make sure they work OLDDIR=`pwd` rm -rf ${EXAMPLESDIR} || true mkdir -p ${EXAMPLESDIR} cd ${EXAMPLESDIR} unzip ${RELEASEDIR}/openjpa-project/target/assembly/*-binary.zip for build in openjpa-*/examples/*/build.xml do ant -f ${build} done cd ${OLDDIR} # Now actually build the javadocs and perform the deploy upload mvn verify deploy -Pjavadoc-profile,sign-release "${EXTRAARGS}" # Remove any identical tag svn delete -m "Removed old ${RELEASEVERSION} tag for re-tagging" ${TAG} || echo "Tag does not already exist, so does not need to be removed" # Now tag the view svn copy -m "OpenJPA Release ${RELEASEVERSION}" \ https://svn.apache.org/repos/asf/incubator/openjpa/trunk \ https://svn.apache.org/repos/asf/incubator/openjpa/tags/${RELEASEVERSION} ${BRANCH} ${TAG} # We don't do this anymore since we release from branches, not from trunk # Update to the next version # perl -pi -e "s;<version>${RELEASEVERSION}</version>;<version>${NEXTVERSION}</version>;g" pom.xml */pom.xml # # # Commit the next versions # svn commit -m "Updated to version ${NEXTVERSION}" |
Resources
- Apache Guide To Release Management During Incubation
- Signing Releases
- Wendy's notes on Release Signing
- Apache Mirroring Guidelines
- Struts Release Instructions (upon which these instructions are based)