Apache releases are not deployments. They are legal artifacts — signed,
voted on by the community, and distributed under the Apache License. Every
PMC member is personally accountable for every release they vote +1 on.
Lab Title What you build
01 Release Checklist Engine Validates a simulated release directory against the ASF release policy checklist 02 API Compatibility Checker Detects REMOVED / ADDED / MODIFIED public methods between two API snapshots; classifies binary-breaking changes 03 RC Vote Parser Parses a [VOTE] email thread; counts binding votes; determines pass/fail per Apache quorum rules
Concept What it means in practice
RC (Release Candidate) A versioned, signed artifact submitted for community vote; may go through multiple iterations (RC1, RC2, …) Binding vote A +1 / 0 / -1 cast by a PMC member; only binding votes count toward quorum Quorum rule ≥ 3 binding +1 votes AND no binding -1 votes → release passes Binary-breaking change A change that prevents existing compiled code from running without recompilation (removed method, changed signature) Source-compatible change A change that requires recompilation but no code edits (new overload, new default method) GPG detached signature .asc file alongside the artifact; lets downloaders verify the release was signed by a known committerSHA-512 checksum .sha512 file; lets downloaders verify artifact integrity after downloadLICENSE / NOTICE Required in every source release; LICENSE covers the ASL-2.0 grant + bundled deps; NOTICE contains required attribution
3 Maven projects, all mvn clean test green
Phase-level HITCHHIKERS-GUIDE.md
"Walk me through the Apache release process" — Phase 10 gives you the full lifecycle answer
"What is a binary-breaking change?" — Lab 02 forces you to implement the detection logic
"How does a lazy consensus vote differ from a full vote?" — covered in HITCHHIKERS-GUIDE.md