Excerpthiddentrue

Instructions for creating an official OpenJPA release

...

Making an OpenJPA 1.0.x or 1.1.x Release

These instructions guide the release manager through the steps of making an official OpenJPA release.

Prerequisites

Prerequisites

1. You should read the OpenJPA Release Policy to decide on the name of the new release, based on the content.
2. You should read the Apache Release FAQYou should have read the Apache Guide To Release Management During Incubation
3. You must have shell access to people.apache.org
4. You must have the following utilities installed on your local machine and available in your path:
   • JDK 1.4 / 1.5
   • ssh
   • Maven 2

...

1. • gnupg
2. For Windows users, install Cygwin in addition to the above utilities
   • Make sure the Net/openssh and Utils/gnupg packages are installed that come with Cygwin installation.
   • Optional: Putty

...

Tasks that need to be performed for each release

...

...

In the examples below, it is assumed that the

...

release name will be 1.0.1, and that the current checked-in version name is 1.0.1-SNAPSHOT and stored in the branch named 1.0.x.

Download the latest rat jar.

run . In general it's a good idea to keep rat.output.txt outside of the code tree for OpenJPA so that it isn't included in the distribution.Look through rat.output.txt for any files that are missing headers. The output will look something like this
Look for !????? files. A complete file can be found here.
As you can see from the example there are some files which do not have license headers. This will be addressed in a future release. Until that time you'll need to evaluate each file on a case by case basis. If you find source code or files which do not have the appropriate headers you should add the header and commit the changes back to trunk.

You can now move the jars from the staging directory on people.apache.org to the incubator repository.
This can be done via the maven-staging-plugin. An early version of this plugin is available in svn.

Monday, 12:00 1	Make sure the #One time setup steps have been performed
2	Run the Release Audit Tool
Code Block
none	none
java -jar ${pathToRat.jar} ${directoryContainingOpenJPA} > rat.output.txt
Code Block
none	none
***************************************************** Summary ------- Notes: 6 Binaries: 33 Archives: 0 Standards: 1270 Apache Licensed: 1261 Generated Documents: 0 JavaDocs are generated and so license header is optional Generated files do not required license headers 9 Unknown Licenses ******************************* Archives (+ indicates readable, $ unreadable): ***************************************************** Files with ASL headers will be marked L Binary files (which do not require ASL headers) will be marked B Compressed archives will be marked A Notices, licenses etc will be marked N N ./README.txt ASL ./pom.xml !????? ./rat.output.txt ASL ./openjpa-all/pom.xml ASL ./openjpa-examples/pom.xml ASL ./openjpa-examples/src/main/java/build.xml ASL ./openjpa-examples/src/main/java/META-INF/persistence.xml
3	Verify that LICENSE.txt contains up to date licenses for any dependencies which are included in our distribution. Any jars or source code which is included with the OpenJPA distribution that is not covered by the Apache license must be noted in LICENSE.txt. Two examples of this are the persistence and orm dtds (licensed under the CDDL) and Serp. If any new non Apache dependencies have been introduced they will have to be covered here as well. If any discrepancies are found update LICENSE.txt and commit the changes.
4	Update BUILDING.txt, CHANGES.txt and RELEASE-NOTES.html
	BUILDING.txt should be included in the source tarball and contains instructions on how to build OpenJPA. Prior to shipping a release we should ensure that those instructions are accurate. CHANGES.txt contains a text representation of all the changes which have been made since the preceding release. Most of the contents of this file can be generated through JIRA's release notes mechanism here RELEASE-NOTES.html contains general information on the OpenJPA project as well as an html version of the changes since the preceding version. The html change log may also be generated via JIRA. Changes made to any of these files should also be made to trunk.
5	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 disruptive advances in the trunk from potentially causing problems with the release. A branch can be made by running:
Code Block
none	none
svn copy -m "OpenJPA Release 0.9.6-incubating" https://svn.apache.org/repos/asf/incubator/openjpa/trunk https://svn.apache.org/repos/asf/incubator/openjpa/branches/0.9.6-incubating
6	Update the POMs to remove "-SNAPSHOT" from the version. If you have perl installed, you can easily do it with a single command:
Code Block
none	none
perl -pi -e 's;<version>0.9.6-incubating-SNAPSHOT</version>;<version>0.9.6-incubating</version>;g' pom.xml */pom.xml
7	Commit the POM changes
Code Block
none	none
svn commit -m "Updated to version 0.9.6-incubating"
8	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):
Code Block
none	none
mvn clean install -Pdocbook-profile,sign-release
	Note This operation will also sign the release files with the gpg utility using the <username>@apache.org key. If your code signing key is under a different address, specify it by appending the following argument to the command above: -Dopenjpa.release.keyAlias=mysigningalias@somedomain.org
9	Verify the signatures:
Code Block
none	none
gpg --multifile --verify openjpa-project/target/assembly/*.asc
10	Now actually build the javadocs and perform the deploy upload using the release profile from settings.xml. This will deploy to a staging directory on people.apache.org instead of deploying to the official incubating repository.
Code Block
none	none
mvn verify deploy -Pjavadoc-profile,sign-release,release
11	Tag the branch with the release number:
Code Block
none	none
svn copy -m "OpenJPA Release 0.9.6-incubating" https://svn.apache.org/repos/asf/incubator/openjpa/branches/0.9.6-incubating https://svn.apache.org/repos/asf/incubator/openjpa/tags/0.9.6-incubating
12	Update the pom.xml files to the subsequent version with the -SNAPSHOT suffix:
Code Block
none	none
perl -pi -e "s;<version>0.9.6-incubating</version>;<version>0.9.7-incubating-SNAPSHOT</version>;g" pom.xml */pom.xml
13	Commit the POM changes
Code Block
none	none
svn commit -m "Updated to version 0.9.7-incubating-SNAPSHOT"
14	Start a vote for the release on the open-jpa-dev@incubator.apache.org mailing list. Votes made by committers and members of the OpenJPA project are considered binding for this vote. For an example of the mail, see this archived vote
15	If the vote is successful after 3 days tally the votes in an email to open-jpa-dev@incubator.apache.org  then mail general@incubator.apache.org starting a vote for authorization to release. For this vote only the members of the IPMC are considered binding. A list of the IPMC members can be found here.
16	Once that vote is successful, update the http://cwiki.apache.org/openjpa/downloads.html page with information about the download
17	The documentation links at http://cwiki.apache.org/openjpa/documentation.html also needs to be updated. You can do this by checking out a copy of the OpenJPA static site documents into a scratch directory, unpacking the OpenJPA binary into the docs section, adding the new docs, and then committing and updating the docs on the server-side:
Code Block
none	none
mkdir /tmp/openjpa-docs/ cd /tmp/openjpa-docs/ jar xvf OPENJPA_DIR/openjpa-project-0.9.6-incubating-binary.zip mkdir /tmp/openjpa-site/ cd /tmp/openjpa-site/ svn co https://svn.apache.org/repos/asf/incubator/openjpa/site/docs cd docs/docs/ mv /tmp/openjpa-docs/openjpa-0.9.6-incubating/docs/ openjpa-0.9.6-incubating rm latest ln -s openjpa-0.9.6-incubating latest svn add openjpa-0.9.6-incubating svn commit -m "Added documentation for openjpa-0.9.6-incubating release" . ssh people.apache.org svn co http://svn.apache.org/repos/asf/incubator/openjpa/site/docs /www/incubator.apache.org/openjpa
	The static site will take a little while to synchronize, but eventually you should see the new documentation version at http://incubator.apache.org/openjpa/docs/. Once you see that, add a link to the new documentation release at http://cwiki.apache.org/openjpa/documentation.html
18
Code Block
none	none
svn co http://svn.apache.org/repos/asf/maven/plugins/trunk/maven-stage-plugin/ maven-stage-plugin cd maven-stage-plugin mvn clean install mvn stage:copy -Dsource="http://people.apache.org/~mikedd/public_html/staging-repository/" \ -Dtarget="scp://people.apache.org/www/people.apache.org/repo/m2-incubating-repository/" \ -Dversion=0.9.7-incubating ## This last step may take some time.
19	Update the JIRA versions page to mark the version as 'released', and set the date to the date that the release was approved.

One time setup

These setup steps only need to be performed on a particular machine once.

Create and install a SSH key

Create a PGP key

Update Maven settings for our servers

...

1

...

Create a settings.xml under .m2 (in your Document and Settings folder in Windows)

...

...

<settings xmlns="http://maven.apache.org/POM/4.0.0"
          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/settings-1.0.0.xsd">
    <servers>
       <server>
          <id>people.apache.org</id>
          <username>$USERNAME</username>
          <privateKey>$PATH_TO_PRIVATE_KEY</privateKey>
          <directoryPermissions>775</directoryPermissions>
          <filePermissions>644</filePermissions>
       </server>
    </servers>    
    <profiles>
        <profile>
            <id>release</id>
            <properties>
                <deploy.altRepository>people.apache.org::default::scp://people.apache.org/home/${APACHE_USER_ID}/public_html/staging-repository</deploy.altRepository>
            </properties>
        </profile>
    </profiles>
</settings>

One time setup

These setup steps only need to be performed on a particular machine once.

...

Developers using Linux workstations can skip over the references to PuTTY and Cygwin

...

Create and install a SSH key

Create a PGP key

Update Maven settings for our servers

Expose a copy of known hosts to Maven

Troubleshooting

Space Character in Build Root Path

Merging local repository to remote repository in Cygwin/Windows

Cygwin/Windows File Path

"Too many unapproved licenses:"

Resources

• Apache Apache Release FAQ

Expose a copy of known hosts to Maven

Example shell script to perform the steps above

...

#!/bin/sh -pve
# Author: Marc Prud'hommeaux <mprudhom@apache.org>
# 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"

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

OLDVERSION=${1}
RELEASEVERSION=${2}

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 ${RELEASEVERSION} || echo "Usage: ${0} OLDVERSION RELEASEVERSION"
test ! -z ${RELEASEVERSION}

# 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}" ${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)