Phase 04 — ASF Governance and Release Engineering
Why this phase exists: A release is a legally binding act. When you vote +1 on an Apache release you are personally attesting that you checked the artifacts, verified the signatures, and believe the code meets the ASF's legal and technical standards. This phase teaches the mechanics of how that actually works.
What You'll Learn
- How Apache releases are planned, branched, and built
- What an RC (Release Candidate) is, how it is built and distributed, and how the vote works
- How GPG signing and SHA-256 checksums create the verifiable chain of custody from committer to end user
- How the Maven Release Plugin automates the mechanical parts of a release
- How to use
japicmpto detect binary and source compatibility regressions before a release ships - Common release failures and how mature projects prevent them
Concepts Covered
| Concept | Where it appears |
|---|---|
| Feature freeze and stabilization branch | Apache release lifecycle |
| RC numbering (RC0, RC1 …) and why RC0 often fails | Vote thread conventions |
| Binding vs non-binding votes, +1 / 0 / -1 semantics | PMC vote thread |
GPG detached signatures (.asc), web of trust, KEYS file | Artifact signing |
| SHA-256 checksums and why they are not a substitute for GPG | Release verification |
mvn release:prepare / mvn release:perform | Maven Release Plugin |
| Binary compatibility vs source compatibility | japicmp / API evolution |
dist.apache.org vs Maven Central — the distribution flow | ASF release infrastructure |
| NOTICE and LICENSE file requirements | Legal obligations |
| Reproducible builds and why they matter | Release integrity |
Labs
| # | Lab | Primary Artifact | What Student Produces |
|---|---|---|---|
| 01 | Release Mechanics | pom.xml + Java source | A tagged, versioned Git commit; Maven-generated RELEASE_NOTES.md stub |
| 02 | Signing and Verification | sign-artifact.sh + verify-release.sh | Two working shell scripts; signed + checksummed artifact |
| 03 | API Compatibility | Multi-module Maven project | japicmp HTML/XML compatibility report; structured compatibility matrix |
Deliverables Checklist
-
mvn release:prepare -DdryRun=trueoutput shows correct version bump and tag name -
mvn release:prepareproduces a Git tag and a bumped SNAPSHOT version -
sign-artifact.shproduces.ascand.sha256files for a given input artifact -
verify-release.shcorrectly verifies both signature and checksum, prints clear pass/fail -
mvn installinlab-03-api-compatibility/produces a japicmp report identifying the planted breaking changes - You can identify all breaking changes in the v1→v2 diff from the japicmp output
Interview Relevance
Every Staff+ distributed systems role at a company that ships open-source software (Databricks, Cloudera, LinkedIn, Uber, Confluent, Elastic) will ask some version of:
- "Walk me through how you would cut a release for an open-source library."
- "What does binary compatibility mean, and how do you validate it before a release?"
- "What's your release checklist look like? What's the worst release failure you've seen?"
- "Why does the Apache release process require GPG signatures? What does it prove?"
This phase gives you concrete, hands-on answers to all four.