Page History

...

Except where noted, all instructions in this guide apply to all three types of releases.  The most common Geode release type is minor (a new major version would only be for breaking changes, and would ideally be preceded by some major discussion on the dev list).  

...

Propose cutting a support branch (major/minor only)

Geode nominally cuts support branches for new minor releases on a time-based schedule (Monday on or after Feb 1, May 1, Aug 1, Nov 1), unless otherwise decided on the dev list.  A week or two before the scheduled date, send a Send a [DISCUSS] email to dev@geode.apache.org proposing that a new support branch be created.  Remind the community that only critical fixes will be allowed once the support branch is created, so it is helpful to have develop as stable as possible before branching.

Note: patch release(s) are initiated by dev list proposal only (not on any time-based schedule), and will include any fixes already accumulated on the support branch(es) plus whatever may be specifically proposed to drive the patch release.  Patch release proposals must be made within nine months of the initial minor release.  

Review LICENSE and NOTICE files

Confirm that the Geode LICENSE and NOTICE files on develop are accurate (ask for help on the dev list if needed).  This is best done before cutting the branch, otherwise be sure to backport any changes to the support branch as well.

Review LICENSE and NOTICE files

Confirm that the Geode LICENSE and NOTICE files on develop are accurate (ask for help on the dev list if needed).  This is best done before cutting the branch, otherwise be sure to backport any changes to the support branch as well.

1. cd .. && ./geode/dev-tools/release/license_review.sh -v HEAD -p 1.12.0 (replace 1.12.0 with the version of the previous release) to check the LICENSE files for missing dependencies or outdated versions and compare dependencies against a previous release.  If any dependencies were removed, manually check for stale references in LICENSE or NOTICE files that can be removed.  If new dependencies were added that have Apache 2.0 License, add them to the license_review script's isApache2 function.  If a new 3rd-party .jar is now appearing in the binary distribution, update geode-assembly/src/main/dist/LICENSE appropriately.   If new 3rd-party intellectual property was checked into the source tree (e.g. a javascript librarycd .. && ./geode/dev-tools/release/license_review.sh -v HEAD -p 1.12.0 (replace 1.12.0 with the version of the previous release) to check the LICENSE files for missing dependencies or outdated versions and compare dependencies against a previous release.  If any dependencies were removed, manually check for stale references in LICENSE or NOTICE files that can be removed.  If new dependencies were added that have Apache 2.0 License, add them to the license_review script's isApache2 function.  If a new 3rd-party .jar is now appearing in the binary distribution, update geode-assembly/src/main/dist/LICENSE appropriately.   If new 3rd-party intellectual property was checked into the source tree (e.g. a javascript library), update both LICENSE and geode-assembly/src/main/dist/LICENSE.

...

1. From one directory above a checkout of latest geode develop, run the create_support_branches script.  This will create branches on all projects and update version numbers appropriately, and guide you though creating the support pipeline, updating Jira, and creating a PR to bump develop to the next version.

   Code Block
   language bash
   cd .. geode/dev-tools/release/create_support_branches.sh -v 1.13 -g your_github_username

   
   

2. Review the benchmark baseline on the support branch.  It should usually be {previous release} 

   See ci/pipelines/shared/jinja.variables.yml around line 20 (under benchmarks:)

   Code Block
   language yml
   baseline_version: '1.12.0'

   
   

3. Send email to dev@geode.apache.org informing the creation of the support branch and requesting feedbackany rules for backporting changes to the branch.

   No Format

   Hello Geode Dev Community, We have created a new support branch for Apache Geode {x.y.0} - "support/{x.y}" Please focus your acceptance testing on this branch and raise any concerns in the next few weeks and raise any concerns in the next few weeks. If any changes are needed please add blocks-{x.y.0} label in Jira and create a PR against support/{x.y}. After some quiet period we will packageprepare a release candidate and begin voting upon it. Regards {Release Manager}

   
   

4. For the duration of the release process, continue to monitor the new release pipeline and address any issues that may arise, including analyzing any test failures (ask for volunteers on the dev list to investigate any failures you are unsure of).

...

Hello Apache Geode Community, 

It's time to update the 3rd-party libraries used by GEODE.  We need a volunteer to take on this responsibility.

https://github.com/apache/geode/blob/develop/dev-tools/dependencies/README.md describes how to carry out this task.

It would be awesome to get this done within the next few weeks, to allow plenty of time to shake out any issues before the next release.

Regards,
{Release Manager} on behalf of the Apache Geode team awesome to get this done within the next few weeks, to allow plenty of time to shake out any issues before the next release.

Regards,
{Release Manager} on behalf of the Apache Geode team

Remove old unsupported branches (major/minor only)

Geode supports N-2 versions (starting since 1.12), so on the day 1.15.0 is released, 1.12 would become no longer supported.

1. remove 1.<N-3> support branch, pipelines and RC tags:

geode/dev-tools/release/end_of_support.sh -v 1.{N-3}

Send the announce mail

To:  user@geode.apache.org, announce@apache.org, dev@geode.apache.org

...