Thanks Kirk, Can you please provide some clarification about the maintenance branches. AFAIK Gitflow procedure requires merging hotfix/maintenance branches back into the main and develop branches as soon as the fixes have been completed. However, you're saying we should not do this? Currently, the 1.15 maintenance branch sits at 79 commits ahead of develop. Shouldn't this be merged into develop prior to the release?
Thanks, William Hodges -----Original Message----- From: Kirk Lund <[email protected]> Sent: Friday, August 29, 2025 4:24 PM To: [email protected] Subject: Re: [DISCUSS] Draft Geode Release Manager runbook EXTERNAL 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 [email protected]. 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 <[email protected]> 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 > > https://prot/ > ect.checkpoint.com%2Fv2%2Fr01%2F___http%3A%2F%2FJinwooHwang.com___.YzJ > 1OnNhc2luc3RpdHV0ZTpjOm86NWMwZDZhMmVhMWU1OGYzYmE5M2YxZDk0ZWQyYjg4YTA6N > zpjN2FiOmUzYzU0YjlmYTM1OTVhMzVmYmEyZmQzYzQ5NjU3NGQ0Y2YzZWUzYTE5NzJhN2I > xYzEyNTdiZjk1YjUzZjhkZGI6cDpUOk4&data=05%7C02%7CWilliam.Hodges%40sas.c > om%7Cc58859e576a243bcab1608dde73a0ce6%7Cb1c14d5c362545b3a4309552373a0c > 2f%7C0%7C0%7C638920958736596708%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcG > kiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoy > fQ%3D%3D%7C0%7C%7C%7C&sdata=CGodhdubyGk7hkLSkWLwUVs48nNfheUzWIGbAZ3%2B > P64%3D&reserved=0<https://nam02.safelinks.protection.outlook.com/?url= > https%3A%2F%2Fprotect.checkpoint.com%2Fv2%2Fr01%2F___http%3A%2F%2Fjinw > oohwang.com%2F___.YzJ1OnNhc2luc3RpdHV0ZTpjOm86NWMwZDZhMmVhMWU1OGYzYmE5 > M2YxZDk0ZWQyYjg4YTA6NzoxMzc3OjMxNTc5MmZmZmY4OTJhOThmYjI4OWYxOTU0MmNmZj > Q0ODBlYzVkMjIzZDNhNWE5NDM2MmU3N2NhMGFhMjBiMzc6cDpUOk4&data=05%7C02%7CW > illiam.Hodges%40sas.com%7Cc58859e576a243bcab1608dde73a0ce6%7Cb1c14d5c3 > 62545b3a4309552373a0c2f%7C0%7C0%7C638920958736619295%7CUnknown%7CTWFpb > GZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkF > OIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=oB%2F4PcDn1zoKcaJOttl > NCRQSzV7RFseu99Z7SbWnJnI%3D&reserved=0> > > > > From: Kirk Lund <[email protected]> > Date: Friday, August 29, 2025 at 1:54 PM > To: [email protected] <[email protected]> > 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 [email protected]<mailto: > [email protected]>, 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 > [email protected]<mailto:[email protected]>). > > 2. Announce your intent > > * Send a short note to [email protected]<mailto: > [email protected]> (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://prot/ > ect.checkpoint.com%2Fv2%2Fr01%2F___http%3A%2F%2Fkeys.openpgp.org___.Yz > J1OnNhc2luc3RpdHV0ZTpjOm86MGJhM2RjMTIxYjFjY2IzODg5YTFiMGFmMTBlOWNlMGE6 > Nzo3OGE3OjBlYmIxYjdjMzU0MTM3MTM4MmUwMGY4NTQzYjgwOWM4OWEyZjI1Y2JlMzVkYj > g4MGFhYTVmNWZmYWQ1NGJmMDY6aDpUOk4&data=05%7C02%7CWilliam.Hodges%40sas. > com%7Cc58859e576a243bcab1608dde73a0ce6%7Cb1c14d5c362545b3a4309552373a0 > c2f%7C0%7C0%7C638920958736629608%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hc > GkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjo > yfQ%3D%3D%7C0%7C%7C%7C&sdata=%2BeqWmnBbkOASVdSUUksh%2B9yoxHvVV1Mi8k%2F > iQ45AKqM%3D&reserved=0>) > so others can fetch it. > > 5. Add your key to Geode’s KEYS file > > * Checkout the Geode dist area: > https://prot/ > ect.checkpoint.com%2Fv2%2Fr01%2F___https%3A%2F%2Fdist.apache.org%2Frep > os%2Fdist%2Frelease%2Fgeode%2F___.YzJ1OnNhc2luc3RpdHV0ZTpjOm86NWMwZDZh > MmVhMWU1OGYzYmE5M2YxZDk0ZWQyYjg4YTA6Nzo0NTgwOjRhMzcwMTcxM2JkYmQ3YTg0MD > MyYzQzYjQxZDY0YTNkZjZlN2JmY2FhOWJhZTljMjdkNjFjMmFjNjk0OTRjODI6cDpUOk4& > data=05%7C02%7CWilliam.Hodges%40sas.com%7Cc58859e576a243bcab1608dde73a > 0ce6%7Cb1c14d5c362545b3a4309552373a0c2f%7C0%7C0%7C638920958736640222%7 > CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlA > iOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=OnVxF > %2FB5Ek%2B3wmfRPItUQ%2FCl%2FhSDjjIwVo1yK%2BSVTB0%3D&reserved=0< > https://prot/ > ect.checkpoint.com%2Fv2%2Fr01%2F___https%3A%2F%2Fdist.apache.org%2Frep > os%2Fdist%2Frelease%2Fgeode%2F___.YzJ1OnNhc2luc3RpdHV0ZTpjOm86MGJhM2Rj > MTIxYjFjY2IzODg5YTFiMGFmMTBlOWNlMGE6NzphNmU4OjRlNmJjZDUzZjM4MWYwYTNjMW > UyYzAzNGYxZjY3YzM0MjVlNzFhYjlmNmQ4NTg4YWM3ZTkyY2QzYzhlYzJhNzY6aDpUOk4& > data=05%7C02%7CWilliam.Hodges%40sas.com%7Cc58859e576a243bcab1608dde73a > 0ce6%7Cb1c14d5c362545b3a4309552373a0c2f%7C0%7C0%7C638920958736651411%7 > CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlA > iOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=TFfFd > b41hMMwQZnZtDqDaOe3PMZsyzs3Tr7bJNM%2Fl7k%3D&reserved=0 > > > > * 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://protect.checkpoint.com/v2/r01/___https://dist.apache.org/repos/dist/dev/geode/___.YzJ1OnNhc2luc3RpdHV0ZTpjOm86NWMwZDZhMmVhMWU1OGYzYmE5M2YxZDk0ZWQyYjg4YTA6NzozMDkzOjdlYmEwMDIxYmY4ODkzMzE1OTNlMTVkMjQ0YmMyNWRhNWFmMzM5N2VjMTkyMmE4ODI5N2I2MzM1MDYwMTgwYzM6cDpUOk4< > https://prot/ > ect.checkpoint.com%2Fv2%2Fr01%2F___https%3A%2F%2Fdist.apache.org%2Frep > os%2Fdist%2Fdev%2Fgeode%2F___.YzJ1OnNhc2luc3RpdHV0ZTpjOm86MGJhM2RjMTIx > YjFjY2IzODg5YTFiMGFmMTBlOWNlMGE6NzphMTgxOjZiZDUwM2RiN2YwYThkOGQ3NDZlOW > U4N2JmZDQ5MmNhY2RkYmQ3ZjczMGRmODg1NDNlYmQ0NDU0YWNhZThkNTY6aDpUOk4&data > =05%7C02%7CWilliam.Hodges%40sas.com%7Cc58859e576a243bcab1608dde73a0ce6 > %7Cb1c14d5c362545b3a4309552373a0c2f%7C0%7C0%7C638920958736673047%7CUnk > nown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJ > XaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=dbfMWFCYH > eOBbz2JILtCYgHcQ%2BTy5yGdRUh4Li9hKfo%3D&reserved=0 > ><version>-RC<N>/ > > * Include the archives plus their .asc and .sha512 files. > > 6. Start the vote on > [email protected]<mailto:[email protected]> > (≥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 [email protected]<mailto: > [email protected]>, 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 [email protected] > <mailto:[email protected]> 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. >
