Considerations for releasing under ASF

Requirements / constraints from ASF

These are constraints we have to work with, and can not change. Do note that this document is not necessarily correct. This part is subject to change as we learn more about the actual requirements set by ASF. The authoritative source are the ASF Incubator Release Management and ASF Software Product Releases documents. Especially relevant to Zipkin, since it's using Maven for most builds, is Publishing Maven Artifacts.

• Formal releases are voted upon by (P)PMCs, and must satisfy a number of conditions (condition list not directly relevant for this discussion)
• Formal release versions are published under https://dist.apache.org/repos/dist/release/
• Nightly and other dev artifacts can be published under https://dist.apache.org/repos/dist/dev/
• SNAPSHOT artifacts can be published under https://repository.apache.org/content/repositories/snapshots/
• Requirements / constraints from Zipkin
•  Display releases on Zipkin website

These are preferences from Zipkin contributors, derived from an understanding of existing development practices and the specific needs and expectations of the Zipkin user community.

• Keep release overhead as low as possible, while satisfying ASF requirements
• Do we want to synchronize releases of the various Zipkin projects?

Options

Release processes of other Apache projects with similar requirements we may learn from:

• Tiles: https://tiles.apache.org/framework/dev/snapshots.html
• Releasing jclouds
• SkyWalking: https://github.com/apache/incubator-skywalking/blob/master/docs/en/guides/How-to-release.md

A. Only formal releases

This is a bare-bones approach minimizing tooling investment. For simplicity, let's examine the release process of the main Zipkin server under this model.

On commits to master:

• Passing CI test jobs on master upload SNAPSHOT artifacts to the shapshots ASF repo, just like they do now (except until now they lived on Sonatype). Artifact: zipkin-server 2.11.6-SNAPSHOT
• No Docker images are built. It's possible to put in some tooling work to allow triggering the build of "snapshot" Docker images from specific JARs.

When tag rc-2.11.6 is pushed:

• Release notes are written and committed into the repo
• CI builds an artifact with version 2.11.6, and uploads it to the dev repo. This will be the final release artifact if the release vote passes.
• This triggers an automated Docker build, creating an image labeled 2.11.6-rc
• Formal vote process takes place. If the vote fails, stop here. If the vote passes:
• The 2.11.6 JAR is promoted to the release Maven repository. The previously built Docker image receives the label 2.11.6. These can initially be done manually, and are great candidates to encapsulate in CI jobs (either started manually on Jenkins, or by pushing a tag release-2.11.6 and utilizing Travis / Circle).
• Release is announced on channels (to be documented before this process is finalized)

B. Only formal releases, with extra tooling to share dev builds

This allows more flexibility in distributing builds that are not official releases.

First: do everything from Option A 

When tag dev-$USER-$FEATURE is pushed, with the current snapshot version being 2.11.7-SNAPSHOT, where $USER wants to get a build to someone so they can try out $FEATURE, or verify a fix, or anything else along those lines:

• CI uploads an artifact 2.11.7-$USER-$FEATURE to the dev repository
• This triggers an automated Docker build, creating an image labeled dev-2.11.7-$USER-$FEATURE.

These artifacts are temporary, and are automatically cleaned up after a month of being uploaded.

C. ???

Add any more ideas here.