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.
>

Reply via email to