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.

Reply via email to