Hi William, I'm only saying that you don't want to blindly merge all 79 commits to develop. Some of those commits may be specific to support/1.15 and thus not applicable to develop. It's also possible that previous committers already merged some of the applicable commits to develop. I think we'll need to carefully analyze each commit to determine its relevance for develop. The community may also want refine this part of the process further going forward.
-Kirk On Tue, Sep 2, 2025 at 12:51 PM William Hodges <[email protected]> wrote: > 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. > > >
