DRAFT Procedure for creating a release using M2
This is currently a discussion page, and is not (yet) policy
Maven2 Release Procedure
As discussed here: http://markmail.org/message/3emjaadwpf7cr5q3
The Commons Parent POM (v10 onwards) defines repositories such that when using the rc profile, uploaded artifacts go to:
The Apache m2-snapshot-repository if a SNAPSHOT version is used (to permit easy testing of RCs by community, for instance)
A staging repository under p.a.o/builds/commons/{component.id}/ if a final version is used
A. Infrastructure Setup (one time)
A.1 Get Familiar with Maven
Reading the Maven documentation is a good start - Releasing A Maven Project.
A.2 Signature Keys
You need to sign the released artifact using your PGP key which implies
- you generated one
- it is uploaded to a key server
- it is signed on a key signing party
it is found in the KEY file (see https://svn.apache.org/repos/asf/commons/trunks-proper)
See also:
A.3 Maven Installation
After having a lot of problems (Oct. 2009) the following configuration is known to work
- Maven 2.2.1
- SVN 1.5.0
However, on Un*x, you may encounter http://jira.codehaus.org/browse/MSITE-404 which will at least prevent staging a site. On Mac, you may also encounter http://jira.codehaus.org/browse/MRELEASE-424 for which there is a workaround.
A.4 Maven Server Settings
It is a good idea to check your settings.xml that it contains the corresponding server entries for the repositories and websites defined in the commons parent pom. If you have a different user name on your box than on people.apache.org you local user name will be used for authentication. Therefore the authentication will fail and after a few retries your are locked out from people.apache.org for a day - which in turn makes cutting a release rather lengthy. In theory you could also provide your password in the server section below but this unsafe and did not work in my case.
<servers>
<server>
<id>apache.releases</id>
<username>YOUR_APACHE_USERNAME</username>
<filePermissions>664</filePermissions>
<directoryPermissions>775</directoryPermissions>
</server>
<server>
<id>apache.website</id>
<username>YOUR_APACHE_USERNAME</username>
<filePermissions>664</filePermissions>
<directoryPermissions>775</directoryPermissions>
</server>
<server>
<id>apache.snapshots</id>
<username>YOUR_APACHE_USERNAME</username>
<filePermissions>664</filePermissions>
<directoryPermissions>775</directoryPermissions>
</server>
</servers>
B. Release Preparation
B.1 Check Your Project
Here you find a list of reminders what to double-check before cutting a release candidate
- Make sure that you are not referencing any SNAPSHOT version (dependencies and plugins) otherwise the release will fail
Make sure that you update the xdocs/changes.xml file to reflect your release
Make sure that all your files contain a ASF licence header (look at the RAT report when in doubt, generated with mvn site)
- Make sure that the LICENSE and NOTICE files are present and correct - especially that the year is correct in the NOTICE file.
- Make sure that you make a test build using a clean checkout
- Make sure that there are no major bugs in JIRA
- Make sure to add all missing committers and contributers
B.2 Prepare Your Version Number
A guideline regarding version numbering can be found at http://commons.apache.org/releases/versioning.html - within Commons we reached the following consensus
- when your release a new major or minor version it comes without point release number, e.g "foo-1.0.jar" or "foo-2.1.jar"
- when doing a bugfix release your need to add the point release number, e.g "foo-1.0.1.jar" or "foo-2.1.1.jar"
B.3 Prepare Your Maven Variables
During the staging process a directory is created on people.apache.org based on the content of the following Maven variables
- commons.release.version is a duplicate of the pom version
- commons.rc.version is the current number of your release candidate
That could look like the following snippet taken from commons-exec
<properties> <commons.release.version>1.0.0</commons.release.version> <commons.rc.version>RC2</commons.rc.version> </properties>
B.4 Update Your Download Page
The commons-build plugin generates a download page in ./src/site/xdoc/ based on commons.release.version
mvn commons:download-page
B.3 Define Staging Site for Release Candidate
Also ensure that the rc profile will stage the site (rather than update the Commons component website). See bottom of Commons SCXML POM as an example. See COMMONSSITE-26 for background.
<profiles>
<profile>
<id>rc</id>
<distributionManagement>
<!-- Cannot define in parent ATM, see COMMONSSITE-26 -->
<site>
<id>apache.website</id>
<name>Apache Commons Release Candidate Staging Site</name>
<url>${commons.deployment.protocol}://people.apache.org/www/people.apache.org/builds/commons/${commons.componentid}/${commons.release.version}/${commons.rc.version}/site</url>
</site>
</distributionManagement>
</profile>
</profiles>
B.5 Prepare Your Assembly Descriptors
If you are declaring/using your own assembly descriptors make sure that they are not using ${version} but ${commons.release.version} - there seems to be an odd bug which results in an incorrectly expanded version string, e.g. commons-exec-2.4.1-src. If in doubt look at ./src/assembly/src.xml
B.6 Commit Your Changes
When you followed the instructions you have modified a couple of files by now - commit them now otherwise the release process will fail.
B.7 Dry Run Your Maven Release
Check that your poms will not lose content when they are rewritten during the release process.
mvn release:prepare -DdryRun=true
Diff the original file pom.xml with the one called pom.xml.tag to see if the license or any other info has been removed. This has been known to happen if the starting <project> tag is not on a single line. The only things that should be different between these files are the <version> and <scm> elements. Any other changes, you must backport yourself to the original pom.xml file and commit before proceeding with the release.
- Remember to do 'mvn release:clean ' before you start the real release process.
C. Run The Release Process
C.1 Stage Artifacts and Site
mvn -Prc release:prepare
mvn -Prc release:perform
C.2 Remove SHA1 and MD5 Fingerprints of PGP Signatures
During the release process some unwanted fingerprints of all ASCII-armored files are generated, e.g. "commons-foo.jar.asc.md5" and "commons-foo.jar.asc.sha1". It is a good idea to remove them manually for the time being.
D. Vote
D.1 Send Out The Vote
Below you find a vote template to save you some time ...
Tag:
https://svn.apache.org/repos/asf/commons/proper/YOUR_PROJECT/tags/${commons.rc.version}
Site:
http://people.apache.org/builds/commons/YOUR_PROJECT/${commons.release.version}/${commons.rc.version}/site/index.html
Binaries:
http://people.apache.org/builds/commons/YOUR_PROJECT/${commons.release.version}/${commons.rc.version}/staged/commons-exec/commons-exec/${commons.release.version}/
[ ] +1 release it
[ ] +0 go ahead I don't care
[ ] -1 no, do not release it because
D.2 React to the Vote
If vote fails, undo and redo previous steps as appropriate (make sure you use a new tag, e.g. if RC2 fails, then create RC3). And rest assured that most releases need more than one release candidate ...
E. Go live
E.1 Copy to "dist"
We need to copy distribution archives to the Commons dist/ area which is located on people.apache.org under /www/www.apache.org/dist/commons. (This content is also automatically copied to archive.apache.org.) We also need to update the "current" symlinks to point to the current version, using the symlinks.sh tool available in https://svn.apache.org/repos/private/committers/tools/releases/symlinks.sh
Here's an example used for commons-dbutils:
cd /www/www.apache.org/dist/commons/dbutils/binaries/ cp /www/people.apache.org/builds/commons/dbutils/1.2/RC3/staged/commons-dbutils/commons-dbutils/1.2/*bin* . cd ../source cp /www/people.apache.org/builds/commons/dbutils/1.2/RC3/staged/commons-dbutils/commons-dbutils/1.2/*src* . cd .. ~/svn/apache-committers/tools/releases/symlinks.sh 1.2
E.2 Copy Artifacts from Staging
The Maven Stage plugin copies the artifacts (from your release candidate) to the M2 sync directory (people.apache.org/repo/m2-ibiblio-rsync-repository).
The following example was used to do the copy the artifacts for commonse-exec-1.0 based on RC5
mvn stage:copy -Dsource="http://people.apache.org/builds/commons/exec/1.0/RC5/staged/" \ -Dtarget="scp://people.apache.org/www/people.apache.org/repo/m2-ibiblio-rsync-repository" \ -DtargetRepositoryId=apache.releases \ -Dversion=1.0
E.3 Deploy the Site
Run mvn site-deploy to deploy the site - please note that you are deploying the site of the next development snapshot.
E.4 Create the SVN Release Tag
If you have used a "RC" tag (e.g. "EXEC_1_0_1_RC5") for the M2 release preparation you need to copy the SVN tag in order to create an official release tag.
The following example was used for creating the release tag on commons-exec-1.0.1
svn copy https://svn.apache.org/repos/asf/commons/proper/exec/tags/EXEC_1_0_1_RC5 \ https://svn.apache.org/repos/asf/commons/proper/exec/tags/EXEC_1_0_1 \ -m "The RC5 passed to vote so this will be the release tag"
F. Celebrate
F.1 Prepare Your Celebration
Make sure a couple of things
- check the project website (mirroring takes a while)
- check the projects download page and download your stuff
check http://www.apache.org/dist/commons if your project shows up
check http://repo1.maven.org/maven2/ and http://people.apache.org/repo/m2-ibiblio-rsync-repository/ if your project artifacts are available
F.2 Send an Announcement
Send an announcement to the developer and user mailing list. Since you have dutifully updated your changes.xml you can generate the announcement in ./target/announcement/
> mvn changes:announcement-generate
G. Tidy up
G.1 Remove old releases
Once the new release has been available for a few days, any files from previous releases should be deleted from the binaries and source directories.
Releasing commons-parent pom
Call a vote with a link showing the changes since the last release - example here
If the vote passes, cut the release using the maven-release-plugin
command svn up (makes sure your svn copy is up-to-date)
command mvn -Prelease release:prepare
command mvn -Prelease release:perform
Procedure for creating a release using M2 (outdated by above)
This assumes that the Commons Proxy is about to vote on 1.0-RC3.
- Tag "proxy-1.0-rc3" but with the version number set to "1.0". This is so the release does not have to be rebuilt later just to fix the version.
- Check out the tag proxy-1.0-rc3 into a clean local working directory
- Build the release artifacts - I think there's a couple of options here:
- Run the following maven command:
mvn site javadoc:jar source:jar assembly:assembly This will create all the artifacts - jars and src and binary distros, but then you need to create checksums and sign (James Carman: link to how to do this?)
- Run the following maven command:
mvn -Prc -DcreateChecksum=true site install This should create all the artifacts installed in your local m2 repository, signed and checksums (note it also creates checksums for signature files - I delete those)
- Run the following maven command:
Upload the artifacts to people.apache.org/~<userid>/proxy-1.0-rc3 (e.g.) and call a vote on dev@ (James Carman: isn't there a mvn command to do this?)
Make sure that your signing key has been added to the commons-wide KEYS file (http://svn.apache.org/repos/asf/commons/trunks-proper/KEYS) found in SVN.
- The vote e-mail should include:
- URL for artifacts
- URL for SVN tag
- URL for website
- If the VOTE passes, then the RC tag can just be copied to the formal release tag, i.e. without the RC suffix. The RC tag should be kept.
- If the VOTE fails, the failed RC tag can be deleted if required.