Hi Kirk, Thank you for taking the time to put together such a valuable document—it's greatly appreciated.
As we prepare for the 1.15.2 release, I noticed that the current support/1.15 branch is 79 commits ahead of develop branch. I wanted to confirm whether we should open pull requests to merge those commits in order to cut the release branch, or if there's a different process we should follow. I appreciate your guidance and support as always. Best regards, Jinwoo Hwang (he/him/his) SAS® Research and Development http://JinwooHwang.com<http://jinwoohwang.com/> From: Kirk Lund <kl...@apache.org> Date: Friday, August 29, 2025 at 1:54 PM To: dev@geode.apache.org <dev@geode.apache.org> Subject: [DISCUSS] Draft Geode Release Manager runbook EXTERNAL 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<mailto: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<mailto:dev@geode.apache.org>). 2. Announce your intent * Send a short note to dev@geode.apache.org<mailto: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<https://protect.checkpoint.com/v2/r01/___http://keys.openpgp.org___.YzJ1OnNhc2luc3RpdHV0ZTpjOm86MGJhM2RjMTIxYjFjY2IzODg5YTFiMGFmMTBlOWNlMGE6Nzo3OGE3OjBlYmIxYjdjMzU0MTM3MTM4MmUwMGY4NTQzYjgwOWM4OWEyZjI1Y2JlMzVkYjg4MGFhYTVmNWZmYWQ1NGJmMDY6aDpUOk4>) 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/<https://protect.checkpoint.com/v2/r01/___https://dist.apache.org/repos/dist/release/geode/___.YzJ1OnNhc2luc3RpdHV0ZTpjOm86MGJhM2RjMTIxYjFjY2IzODg5YTFiMGFmMTBlOWNlMGE6NzphNmU4OjRlNmJjZDUzZjM4MWYwYTNjMWUyYzAzNGYxZjY3YzM0MjVlNzFhYjlmNmQ4NTg4YWM3ZTkyY2QzYzhlYzJhNzY6aDpUOk4> * 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/<https://protect.checkpoint.com/v2/r01/___https://dist.apache.org/repos/dist/dev/geode/___.YzJ1OnNhc2luc3RpdHV0ZTpjOm86MGJhM2RjMTIxYjFjY2IzODg5YTFiMGFmMTBlOWNlMGE6NzphMTgxOjZiZDUwM2RiN2YwYThkOGQ3NDZlOWU4N2JmZDQ5MmNhY2RkYmQ3ZjczMGRmODg1NDNlYmQ0NDU0YWNhZThkNTY6aDpUOk4><version>-RC<N>/ * Include the archives plus their .asc and .sha512 files. 6. Start the vote on dev@geode.apache.org<mailto: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<mailto: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<mailto: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.