Status
Draft. Starting at around this e-mail, the zipkin-dev
mailing list started to discuss what exactly Zipkin releases under ASF would look like. This is a complex topic, and this document is a whiteboard to capture it. This should then lead to a proposal, and a decision, the result of which might be captured here or somewhere else.
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 label2.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 tagrelease-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.
3 Comments
Adrian Cole
incidentally this reminds me a little of the piece we wrote "how change works" https://zipkin.io/pages/community.html
Adrian Cole
do we want to describe CI here or only release?
Zoltán Nagy
What do you mean by CI in this context? My understanding is we keep the current systems (Travis, Circle), so the only CI-related change would be implementing whatever process we come up here in the existing automation.