You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

DRAFT

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. bin.zip, 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 https://dist.apache.org/repos/dist/release/commons/<component>

Maven jar process

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

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.

This can easily be done by defining -Dassembly.attach=false on the command-line or adding <attach>false</attach> to the plugin config in the release profile

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 https://dist.apache.org/repos/dist/dev/commons/<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. See https://issues.apache.org/jira/browse/INFRA-4144

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

  • No labels