commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <>
Subject [Commons Wiki] Update of "ReleaselDeployment" by sebbapache
Date Thu, 06 Jun 2013 11:03:59 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Commons Wiki" for change notification.

The "ReleaselDeployment" page has been changed by sebbapache:

Draft of release process options

New page:

Discussion page on release deployment strategy.
It's easier to keep track of proposals and amend them in the Wiki
Once agreed, this page will need to be incorporated into the Commons website

== Introduction ==

The current release process for tarballs (e.g., src.tar.gz) is a bit long-winded and
error prone.
This page is intended to discuss some possible options and keep track of progress.

== Goals of release process ==

There are several goals that the release process needs to fulfil.

 * create the artifacts (tarball / jar) and hashes
 * RM signs the artifacts
 * Provide staging area(s) for both tarballs and Maven jars
 * Clearly identify the artifacts that are to be voted on
 * Make it easy for reviewers to check the artifacts forming part of the release
 * Traceability of artifacts from vote to release directories
 * Maven jars are released to Maven Central via Nexus
 * Component tarballs are released to the ASF mirror system via<component>

== Maven jar process ==

[This is just for completeness, changes to the Maven release process are not being considered

These are deployed to the Nexus staging area via Maven deploy.
The staging area is then published in the VOTE e-mail.
If the RC vote succeeds, the staging area is promote to release state, and Nexus ensures that
the artifacts are copied to Maven Central.
If the RC vote fails, the staging area is deleted.

== Current tarball process ==

The tarballs are created using the Maven assembly plugin.
This is currently configured to attach the artifacts to the build, which means that they are
included in the signing process and hashes will be created.

It also means that the tarballs are included in the deploy phase, which in turn means that
the tarballs are uploaded to the Nexus staging area.
This has some advantages and some disadvantages.

=== Advantages ===
 * all the artifacts for a release are in a single staging directory
  * so it is easier to download them for RC vote checking.
  * if the RC fails, there is no other directory to clean up
 * GPG signing includes the tarballs in the set of files it signs
 *  hashes are created for the tarballs

=== Disadvantages ===
 * once the RC completes, the tarballs have to be copied from Nexus to the release directory
in SVN.
This process is quite awkward.
 * the tarballs should then be deleted from Nexus; this stage is error-prone as it's easy
to delete the wrong files.

== Alternative tarball process ==

An alternative approach would be to detach the tarballs from the build.

=== Advantages ===
 * no need to copy/delete the tarballs from Nexus
 * SVN traceability of tarballs from dev to release folder

=== Disadvantages ===
 * tarballs will need to be uploaded to<component>
(will need script/new Maven plugin to do this)
 * If RC fails, tarballs have to be removed
 * if RC succeeds, tarballs still have to be moved from dist/dev to dist/release directory;
this needs a script/plugin
 * will need to update pom(s) to sign the tarballs (hopefully just once in CP)
 * update poms to create the hashes (hopefully just once in CP)

== Longshot: Update Nexus to allow it to stage tarballs as well as Maven jars ==

This was proposed a long time ago, but in spite of initial enthusiasm, nothing came of it.

This would be a good solution, but unfortunately it seems very unlikely to happen.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message