Page History

Make sure the #One time setup steps have been performed

Run the Release Audit Tool

Create a sub-branch off of the parent 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:

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.

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.
  

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:

Update the POMs to remove "-SNAPSHOT" from the version. If you have perl installed, you can easily do it with a single command:

Commit the POM changes

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):

Verify the signatures:

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.

Tag the branch with the release number:

Update the pom.xml files to the subsequent version with the -SNAPSHOT suffix:

Check out a clean branch from which to build the release:

svn checkout https://svn.apache.org/repos/asf/openjpa/branches/1.0.1
cd 1.0.1

Update all the POMs to remove "-SNAPSHOT" suffix from the version. If you have perl installed, you can easily do it with a single command:

perl -pi -e "s;<version>1.0.1-SNAPSHOT</version>;<version>1.0.1</version>;g" pom.xml */pom.xml */*/pom.xml

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.

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.
  

Commit the POM changes

Commit the POM changes

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

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.

Once that vote is successful, update the http://cwiki.apache.org/openjpa/downloads.html page with information about the download

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:

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

Update the JIRA versions page to mark the version as 'released', and set the date to the date that the release was approved.

Install PuTTY

Use PuttyGen to create a SSH key (see Putty help for details)

Use PuTTY to ssh to people.apache.org

Create a ~/.ssh folder

pscp your SSH public key to ~/authorized_keys

ssh to p.a.o

Create a ~\.ssh folder and move authorized_keys there

Configure putty to use your private key and save the session

Perform an initial build and install it in the local repository (this step is only required because of an open bug with Maven's javadoc plugin):

mvn clean install -Dtest=false

Now build the release locally, which will build and test, run the Apache Release Audit Tool to verify license headers, generate the javadoc and docbook PDF and HTML, run through the JPA TCK, build the source and binariy assemblies in target/site/downloads/, and sign the release files.

export MAVEN_OPTS=-Xmx1000m
mvn --batch-mode deploy site -Ptest-derby -Ptck-profile -Pexamples-profile \
    -Plicense-verify-profile -Pjavadoc-profile -Pdocbook-profile -Psign-release \
    -Djava14.jar=${JAVA_HOME}/../../1.4/Classes/classes.jar \
    -Dtck.zip=${HOME}/.m2/privaterepos/jpa-1_0b-tck.zip

Verify the signatures:

Upload the release candidate to http://openjpa.apache.org/builds/1.0.1/downloads/:

mvn site:deploy

Start a vote for the release on the dev@openjpa.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 1.0.0 vote

While waiting for the vote to complete, perform whatever manual review and testing on the release you deem appropriate.

If the vote is successful after 3 days tally the votes in an email to dev@openjpa.apache.org, like this one.

Make the OpenJPA assemblies available to the Apache mirroring system by copying them over on people.apache.org:

ssh people.apache.org
cp -r /www/openjpa.apache.org/builds/1.0.1/downloads /www/www.apache.org/dist/openjpa/1.0.1

Now that the release is locked down, convert the writeable 1.0.1 branch to a (du jure) read-only tag:

svn mv -m "OpenJPA Release 1.0.1 tag" \
  https://svn.apache.org/repos/asf/openjpa/branches/1.0.1 \
  https://svn.apache.org/repos/asf/openjpa/tags/1.0.1

Check out the parent branch and bump up the release number to be the next snapshot version:

svn checkout 

Install cgywin, including utils/gpg

Generate a key with $ gpg --gen-key

Backup your cygwin home directory to another media

Update the http://cwiki.apache.org/openjpa/downloads.html page with links to the download mirrors, using the existing entries as templates.

The documentation on the server-side must manually be extracted on people.apache.org, and the links at http://openjpa.apache.org/documentation.html need to be updated with the new versions and the "latest" documentation symbolic links need to be updated:

cd /www/openjpa.apache.org/builds/1.0.1/
unzip downloads/apache-openjpa-1.0.1-binary.zip
rm /www/openjpa.apache.org/docs/latest
ln -fvs ../builds/1.0.1/apache-openjpa-1.0.1/docs/ /www/openjpa.apache.org/docs/latest

Then point the links on http://openjpa.apache.org/documentation.html to:

• HTML Manual: http://openjpa.apache.org/builds/1.0.1/apache-openjpa-1.0.1/docs/manual/index.html
  
• HTML Manual (single-page): http://openjpa.apache.org/builds/1.0.1/apache-openjpa-1.0.1/docs/manual/manual.html
  
• PDF Manual: http://openjpa.apache.org/builds/1.0.1/apache-openjpa-1.0.1/docs/manual/manual.pdf
  
• Javadocs: http://openjpa.apache.org/builds/1.0.1/apache-openjpa-1.0.1/docs/javadoc/index.html
  

Merge the staged maven2 repository jars to with the official repository to rsync. This is currently a difficult process that requires the maven-staging-plugin, which much be built from source. The process looks something like this (executed in the root of your local OpenJPA checkout):

svn co http://svn.apache.org/repos/asf/maven/plugins/trunk/maven-stage-plugin/ /tmp/maven-stage-plugin
mvn -f /tmp/maven-stage-plugin/pom.xml clean install
find . \
    -name m2-repository -not -path "*openjpa-project*" \
    -exec mvn -f /tmp/maven-stage-plugin \
    stage:copy -Dsource=file://{} \
    -Dtarget=scp://people.apache.org/www/people.apache.org/repo/m2-ibiblio-rsync-repository \
    -Dversion=1.0.1 \;

Update the JIRA versions page to mark the version as "released", and set the date to the date that the release was approved. You may also need to make a new release entry for the subsequent release.

After the mirrors have had time to update (24 hours to be on the safe side), make a news announcement on the OpenJPA wiki.

Make an announcement about the release on the users@openjpa.apache.org list (and, for major releases, on the announce@apache.org list as per the Apache Announcement Mailing Lists page). The announcement might look something like this.

Make an announcement for the freshmeat.net OpenJPA project (optional)

Have a beer and enjoy your weekend while the world's grateful programmers revel in yet another high-quality release of Apache OpenJPA!

Install PuTTY

Use PuttyGen to create a SSH key (see Putty help for details)

Use PuTTY to ssh to people.apache.org

Create a ~/.ssh folder

pscp your SSH public key to ~/authorized_keys

ssh to people.apache.org

Create a ~\.ssh folder and move authorized_keys there

Configure putty to use your private key and save the session

Install cgywin, including utils/gpg

Generate a key with $ gpg --gen-key

Backup your cygwin home directory to another media

Add your key to https://svn.apache.org/repos/asf/openjpa/site/docs/KEYS

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

From cygwin, ssh to people.apache.org, save the public key if prompted, and exit

cygwin will save the known hosts to your ~/.ssh folder, but the script cannot access it there (from Windows)

From cygwin (not Windows) create another .ssh folder at

Copy the known_hosts file to the new .ssh folder

From cygwin, ssh to people.apache.org, save the public key if prompted, and exit

cygwin will save the known hosts to your ~/.ssh folder, but the script cannot access it there (from Windows)

From cygwin (not Windows) create another .ssh folder at

Copy the known_hosts file to the new .ssh folder