Hi all,
Here’s an *infrastructure-agnostic write-up of what I remember*.
It’s basically just a new, simplified, Release-Manager-centric way to
present the same info and provide more details in a few areas.
If this looks correct to others then maybe I should add a new Confluence
page or weave this into the existing *“Release Apache Geode”* page entry,
which goes into great detail about the old tooling and VMware pipelines
that are now outdated.
*Quick note on voting:* anyone can vote on dev@geode.apache.org, but *only
Geode PMC votes are binding* (the release requires 3+ binding +1s and a
≥72h vote window).
------------------------------
Apache Geode Release Manager Runbook (Geode-specific)
This runbook captures *how we do Geode releases* and *how someone
volunteers to be Release Manager (RM)*. Geode-specific paths, names, and
expectations are called out explicitly.
------------------------------
A) Volunteering to be the Geode Release Manager
*Purpose:* establish who’s running the release and ensure they can produce
verifiable signed artifacts.
1.
*Confirm eligibility*
-
You’re an *Apache Geode committer* (binding PMC votes come later
during the release vote, but the RM can be a committer).
-
You’re available to drive the RC cycle (coordination on
dev@geode.apache.org).
2.
*Announce your intent*
-
Send a short note to dev@geode.apache.org (subject: [DISCUSS]
Volunteer RM for Geode <version>). If there are multiple volunteers,
decide amicably who takes *RM* and who helps as *shadow RM*.
3.
*Prepare your OpenPGP signing key (one-time per person)*
-
Create a key (ed25519 or RSA-4096).
-
Verify your key has a non-expired expiration date and a recognizable
UID (your Apache email recommended).
4.
*Publish your public key*
-
Export ASCII-armored public key and publish to a keyserver (e.g.,
keys.openpgp.org) so others can fetch it.
5.
*Add your key to Geode’s KEYS file*
-
Checkout the Geode dist area:
https://dist.apache.org/repos/dist/release/geode/
-
Append your public key to *KEYS* and commit.
-
This ensures users and voters can verify your signatures for Geode
releases.
6.
*Local tooling sanity checks*
-
Ensure gpg works in non-TUI mode, you can create *detached ASCII
signatures* (.asc), and you have utilities for checksums (sha512sum
or equivalent).
-
Ensure you can deploy to *ASF Nexus* (Maven staging) with your Apache
credentials and that your Maven settings.xml is configured
appropriately.
Once steps 1–6 are complete, you’re ready to act as *Release Manager for
Geode*.
------------------------------
B) Geode Release Steps (performed by the RM)
*Scope:* from cutting the release branch/tag through vote, promotion, and
publication. Geode-specific repos/paths are used throughout.
1.
*Cut the release branch & tag*
-
Branch from the intended baseline (e.g., release/1.16.0 or whatever
Geode is using).
-
Bump version numbers, update CHANGELOG/RELEASE NOTES, LICENSE/NOTICE
as needed.
-
Create a signed tag for the RC base if the project convention uses RC
tags (e.g., rel/v1.16.0-RC1).
2.
*Build release artifacts*
-
Produce *source* archive (required by Apache) and optional *binary*
archive if Geode ships one:
-
apache-geode-<version>-src.tar.gz
-
apache-geode-<version>-bin.tar.gz (if applicable)
3.
*Sign and checksum the archives*
-
For each archive: create *detached ASCII PGP signature* (.asc).
-
Generate *SHA-512* checksum files (.sha512).
-
Note: For the *ASF release vote*, we sign the *archives* (not each
JAR inside). Per-artifact signatures for JARs are handled during Maven
Central staging.
4.
*Stage Maven artifacts for Central (do not release yet)*
-
Deploy with the Geode release profile so that JARs, POMs, sources,
and javadocs are signed.
-
Close the staged repository in *ASF Nexus* but *do not release* until
the vote passes.
5.
*Upload the Release Candidate to dist/dev*
-
Commit the RC to:
-
https://dist.apache.org/repos/dist/dev/geode/<version>-RC<N>/
-
Include the archives plus their .asc and .sha512 files.
6.
*Start the vote on dev@geode.apache.org <dev@geode.apache.org> (≥72
hours)*
-
Email subject: [VOTE] Apache Geode <version> RC<N>
-
Include links to:
-
The RC in dist/dev
-
The *KEYS* file for Geode (under dist/release/geode/KEYS)
-
The Nexus staging repository URL
-
Verification steps (sig/checksum commands, building from source,
license/RAT checks)
-
*Anyone can vote on dev@geode.apache.org <dev@geode.apache.org>, but
only PMC member votes are binding.* Approval requires *3+ binding +1
PMC votes*, and the vote must be open at least *72 hours*.
7.
*If issues are found*
-
Cancel/close the vote, address the issues, increment RC (e.g., RC2),
and repeat steps 2–6.
8.
*Promote on success*
-
After a successful vote, *promote* the release:
-
Copy the approved artifacts from dist/dev/geode/<version>-RC<N>/
to dist/release/geode/<version>/.
-
Only supported releases live in dist/release; older ones get
archived automatically by ASF infra.
9.
*Publish to Maven Central*
-
In ASF Nexus, *Release* the previously closed staging repository so
artifacts sync to Maven Central.
10.
*Finalize communications & site updates*
-
Push the final git tag (if you staged from a temporary tag).
-
Update the Geode website/downloads/release notes as per project
convention.
-
Send an announce note to project lists (and annou...@apache.org if
appropriate).
------------------------------
*Notes:*
-
ASF release vote = sign source/bin tarballs, not every JAR. Maven
Central staging handles per-JAR .asc.
-
*Voting:* anyone may vote on dev@, but only *PMC votes are binding*.
-
Make sure your key is present in Geode’s KEYS file *before* starting a
vote.
------------------------------
Thanks for reviewing. If this matches our current understanding, I can
polish it into Confluence either as a new page or merged into the
existing *Release
Apache Geode* page.
