Hi Jinwoo, No we don't want to merge or cherry-pick all commits from support/1.15. Many or even all of those may be specific to that version only.
Note: Geode uses git-flow as its style for branching/tagging/releasing. I think the following defines what we should be doing going forward for releasing 1.15.2: Apache Geode 1.15.2 – Current Release Process 1. Where we start - *Active branch*: support/1.15 is the maintenance branch for the 1.15 train. - *Target release*: 1.15.2 (a patch release). - *Release tags*: Geode uses tags like rel/v1.15.2-RC1 … rel/v1.15.2-RC<N> for release candidates, and rel/v1.15.2 for the final GA release. Example from earlier trains: - rel/v1.12.0-RC1 … rel/v1.12.0-RC9 - rel/v1.12.0 (final release) 2. Cutting a release candidate 1. Check out the support branch: git checkout support/1.15 git pull origin support/1.15 2. Create a signed RC tag (numbered sequentially): git tag -s rel/v1.15.2-RC1 -m "Apache Geode 1.15.2 RC1" git push origin rel/v1.15.2-RC1 3. Build, sign, checksum, and stage artifacts as per the RM runbook. 4. Call a vote on dev@geode.apache.org. Repeat with -RC2, -RC3, etc. if fixes are needed. 3. Finalizing the release When the vote passes (≥3 binding +1 PMC votes, ≥72h): 1. Tag the final release on support/1.15: git tag -s rel/v1.15.2 -m "Apache Geode 1.15.2" git push origin rel/v1.15.2 2. Publish release artifacts, close Nexus staging, move dist/dev → dist/release, and send announce mail. *Note:* We do *not* merge support/1.15 into main, because main is tracking the newer 2.x train. Patch releases for older trains stay on their support branch. 4. Forward-porting commits to develop - Every commit on support/1.15 since the last port sweep must be reviewed. - Maintain a simple spreadsheet/log: Commit JIRA Description Forward to develop? (Y/N) abc123 GEODE-12345 Fix NPE in Region destroy Y def456 GEODE-12346 Update 1.15 RC version number N - After 1.15.2 ships, work through this list in order: - Cherry-pick “Yes” commits into develop. - Open PRs (batched if logical). - Skip commits that are release-plumbing or 1.15-only stabilization. This ensures bug fixes don’t get stranded on the support line. ------------------------------ So right now for *1.15.2*: - Work only on support/1.15. - Tag RCs as rel/v1.15.2-RC<N>, final as rel/v1.15.2. - Release from those tags. - Afterwards, sweep commits for forward-ports to develop. - Leave main untouched, since it represents the current train. On Fri, Aug 29, 2025 at 11:23 AM Jinwoo Hwang <jinwoo.hw...@sas.com.invalid> wrote: > 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. >