We need a convenient, uniform way to build Clojure and contrib projects. Problems are

Near-term Process


The inheritance diagram of POMs:


Release Process

"Releasing" Snapshots

Deployment of SNAPSHOTs to the OSS repo is entirely straightforward:

Releasing Releases

The release process involves some additional steps, and some added process/policy may be desirable.

Right now, the build.poms and tools.nrepl Hudson jobs are configured to support the most straightforward/naïve release process possible:

  1. Click "Perform Maven Release" on the job's main page.
  2. Specify the release and development versions to be provided to maven-release-plugin:
    1. release version The version of the release to be built and deployed to the OSS repo, thereupon to central
    2. development version The version that the project's POM(s) will be updated to in git HEAD via a post-release push.

Suggestions for these are usually provided, based on the last version known to Hudson, e.g. if HEAD has a version of 1.0.0-SNAPSHOT, release and dev versions of 1.0.0 and 1.0.1-SNAPSHOT respectively.

  1. The maven release plugin does a few things worth noting:
    1. in the hudson-local git repo, it:
      1. commits an updated project POM with the release version, tagging that changeset with a corresponding tag
      2. commits another updated project POM with the development version, leaving this changeset as master
    2. it performs a clean clone of the hudson-local git repo, checking out the tagged release changeset
    3. in rough terms, performs an mvn clean deploy, targeting the Sonatype OSS releases repository
  2. The deploy operation will create or add to an org.clojure-specific release staging repository in the OSS Nexus instance.
  3. The naïve part: after the deploy operation completes, we automatically close and promote the staging repository's contents to the OSS releases repo, and therefore to central
  4. Once the mvn invocation completes successfully, a post-maven build step pushes master and the release tag to the upstream github repo

This process may or may not be sufficient.  The uncertainty centers on the interaction with the Nexus release staging repository.  Some thoughts:

Given the above, questions include:

  1. Will we want to vet individual release artifacts in any way just prior to their staging repository being promoted to central (similar to e.g. Apache)?
  2. Will we want to attempt to coordinate releases in any way, at the point of staging repository promotion?
    1. This would imply not closing our staging repository automatically as part of our projects' release builds.
    2. Once we've deployed whichever projects we aim to release in a coordinated fashion to the staging repository, we then manually close that repo.
    3. After verifying that the batch of staged artifacts pass our final criteria, we then manually promote their staging repo.
    4. If those artifacts are not acceptable, we can then drop the staging repository, and revisit whatever issues were exposed in our final testing.
      1. Note that this would require us backing out the versioning changes in the projects' POM(s) in SCM (again, presumably a manual operation) without stomping on any substantive patches applied in the interim.

I've written before about how coordinated releases should be off the table; the dynamics of staging repository closing and promotion would seem to make that prospect even less attractive, if only because of the serious pain that would result if we were to back out committed and pushed versioning changes (the automatic handling of which is a no-brainer IMO).

Vetting individual release artifacts would seem to be a more feasible option, if so desired (at least the pain of backing out project version changes would be localized to the project with the problematic release).

However, in both cases, I'd suggest that having multiple alpha and RC releases should eliminate all technical reasons for vetting of staged release artifacts.  At the very least, I'd say that it's worth trying to use the naïve approach through one full release cycle, if only because it's the simplest fully-automated solution available.

- Chas

Possible Future Development