Page History

...

1. git →  https://git-scm.com/downloads
2. docker → https://docs.docker.com/docker-for-mac/install/ 
3. svn → shipped with MacOS  [on Mac, install with command line tools → https://stackoverflow.com/questions/9329243/xcode-install-command-line-tools]
4. gpg tools → https://gpgtools.orgweb
5. browser → java JDK8 → https://support.google.com/chrome/answer/95346?co=GENIE.Platform%3DDesktop&hl=enjava JDK → adoptopenjdk.net
6. Homebrew (optional) → https://brew.sh/
7. fly → use platform-appropriate download link in bottom right corner of https://docsconcourse.oracle.com/javase/8/docs/technotes/guides/install/install_overview.html
8. text editor : vi → should be pre-installed
9. Homebrew → https://brew.sh/
10. fly → use platform-appropriate download link in bottom right corner of https://concourse.apachegeode-ci.info
11. apachegeode-ci.info
12. cmake, doxygen, and openssl - install using an appropriate package manager, e.g. on Mac: cmake, doxygen, and openssl - install with brew on mac ( brew install doxygen && brew install cmake && brew install openssl)
13. text editor (vi or whatever you prefer)
14. web browser

Permission and keys

...

Geode cuts release branches on a time-based schedule (Monday on or after Nov 1, Feb 1, May 1, Aug 1, Nov 1).  About a week before, send a [DISCUSS] email to dev@geode.apache.org informing developers that a new release branch is about to be created.  Remind the community that only critical fixes will be allowed once the release branch is created, so it is helpful to have develop as stable as possible before branching.

...

1. Check for the most recent develop SHA that passes all the tests and contains all the features / bug fixes that need to go into the release at https://concourse.apachegeode-ci.info/beta/teams/main/pipelines/develop/jobs/UpdatePassingRef.
2. Ensure that all JIRA tickets mentioned in commits (since the last release branch was cut) are marked as Resolved in JIRA.  If not, ask assignees if there is still more work to be done.
3. Ensure in JIRA, that all tickets with {version} as the fix version are either closed or resolved. If not inform the the assignees to either mark it Resolved or  increment the fix version.

4. Create the release branch (from HEAD should be fine, or if necessary you can specify a particular SHA), such as the last commit that passed the develop pipeline successfully)

   Code Block
   language bash
   git checkout develop git checkout -b release/{version} [GOOD_SHA]

   
   

5. Update the version number in gradle.properties (and remove -SNAPSHOT)

6. Update the version number in ci/pipelines/geode-build/jinja.template.yml

7. Change SNAPSHOT to "" for SEMVER_PRERELEASE_TOKEN in ci/pipelines/meta/meta.properties

8. Update the version number in all the expected pom files:

   Code Block
   language bash
   ./gradlew clean ./gradlew build -Dskip.tests=true #note: ok if build fails expected pom test ./gradlew updateExpectedPom

    

9. Review the benchmark baseline.  It should be the more recent of {previous release} or develop/highwater.  branch should stay as develop even for release branches.  Note: as the release progresses, consider creating and using a dedicated version/highwater tag on the release branch.

   See ci/pipelines/shared/jinja.variables.yml around line 19:

   Code Block
   language yml
   benchmarks: baseline_branch: develop/highwater baseline_version: '' branch: develop

   
   

10. Publish the release branch to origin

    Code Block
    language bash
    git add . git commit -a -m "Upgraded version number for releasing {version}" git push origin HEAD

    
    

11. Now checkout the repo for geode-examples (apache/geode-examples.git) and create a release branch.

    Code Block
    language bash
    git clone git@github.com:apache/geode-examples.git git checkout develop origin/develop git checkout -b release/{version}

    
    

12. Update the version number in gradle.properties of geode-examples and remove -SNAPSHOT

    No Format
    version = 1.7.0 geodeVersion = 1.7.0

    
    

13. Commit the version changes and push the release branch of geode-examples

    
    

    Code Block
    language bash
    git add -p git commit git push origin HEAD

    
    

14. Checkout the repo for geode-native (apache/geode-native.git) and create a release branch

    
    

    Code Block
    language bash
    git checkout develop git checkout -b release/{version} git push origin HEAD

    
    

15. Send email to dev@geode.apache.org informing the creation of the release branch and requesting feedback.

    No Format
    Hello Geode Dev Community, We have created a new release branch for Apache Geode {version} - "release/{version}" Please do review and raise any concern with the release branch. If no concerns are raised, we will start with the voting for the release candidate soon. Regards {Release Manager}

    
    

16. Create the concourse release pipeline.

    Code Block
    language bash
    fly -t concourse.apachegeode-ci.info login --concourse-url https://concourse.apachegeode-ci.info/ cd ci/pipelines/meta ./deploy_meta.sh

    
    

17. Monitor the new release pipeline and resolve any issues that may arise. 

...

If three +1's are received and no minus 1's, the release manage manager should:

• confirm that the ticket is already in a resolved state on develop
• confirm the exact commits on develop
• cherry pick to the release branch
  • git cherry-pick -x {SHA} && ./gradlew build 
  • if fix does not cherry-pick and build cleanly, ask that a PR be submitted against the release branch
• send a notification to the thread and mark the issue with the correct fixed-in version in Jira:

...

Please note that there is no required voting period to bring a critical fix; it can be merged immediately upon getting 3 +1's.  However, the release manager should be prepared to monitor and revert it from the release branch if it causes test problems, or further discussion of the fix leads to any "minus 1".

Create the release candidate

1. From one directory above a checkout of latest geode develop, run the prepare_rc.sh script (a release-n.n.n-workspace dir will be created in the current directory, so you may not want to be inside your geode checkout when you run it or IntelliJ will get very slow).  This script assumes there is a release/X.Y.Z branch pushed to all of the geode repositories (geode, geode-native, and geode-examples). It  It will checkout the tip of that branch for all repos, build them, and prepare the artifacts. It will also prepare RC tags in each repository and finally pre-stage to nexus.  Run this command on a machine with a GUI as you will be prompted to enter PGP passphrase several times and finally your  Do not run this in a remote shell or headless environment, as a GUI is required to prompt for your PGP passphrase (several times) and lstly your ASF LDAP password (Apache password). Do not include @apache.org in your apache username.

   Code Block
   geode/dev-tools/release/prepare_rc.sh -v version_with_rc -k your_8_digit_key_id -a your_apache_ldap_username

   
   

2. The "next steps" printed out at the end of the prepare_rc script will walk you through the remaining steps to stage to finalize nexus staging (pictured below), publish the release candidate, and send the VOTE email.

3. 

If there is an older geode staging repository listed (from a previous RC, make sure you drop it. Find "orgapachegeode-####" and click on "Drop"Image Removed-####" and click on "Drop"

Image Added

Sanity Check

Some ideas of things you might want to verify before giving the RC to the community to validate:

• build each repo from source tag
• build each product from source tgz
• try building with clean gradle and maven caches (or spin up a new VM for super-clean testing)
• verify signatures (not on same machine where RC was built, again a new VM can be helpful)
• Run Dan's Script 

Send out an email announcing the RC

...

1. from the same directory you were in when you ran the previous release scripts, run promote_rc.sh (note: you must be a Geode PMC member to commit to dist/release/geode):

   Code Block
   geode/dev-tools/release/promote_rc.sh -v version_with_rc -k 'your_840_digit_gpg_key_id' -g your_github_username

   
   

2. The "next steps" printed out at the end of the promote_rc script will walk you through the remaining steps to release the staged artifacts in nexus (pictured below), make the brew PR, validate the docker image, update Jira, wait for mirrors to sync, and finalize the release.
   
   

...

*** this is a good time to go home / take a nap / finish it tomorrow.  mirror sites can take 8-24 hours to sync, and the remaining steps depend on most or all mirrors being up-to-date.call it a day...mirrors take overnight to sync the new release ***

Finalize the release

1. Confirm that your brew PR has been closed and brew install apache-geode picks up the new release.  

   Code Block
   brew install apache-geode gfsh version

   
   

2. From from the same directory you were in when you ran the previous release scripts, run finalize_release.sh:

geode/dev-tools/release/finalize_release.sh -v version_without_rc -k full_40_character_gpg_fingerprint -g your_github_usernamerelease/finalize_release.sh -v version_without_rc

The "next steps" printed out at the end of the finalize_release script will walk you through the remaining steps to make the brew PR, validate the docker image, update mirror links, publish docs site, and send the official release announcement.

Note: The brew team usually accepts the PR within 24 hours.  Note: they may close it without merging.  Either way, check that latest version has been added to brew by doing brew install apache-geode.  

Publish javadocs and documentation to the website

...

The Apache Geode community is pleased to announce the availability of
Apache Geode {version}.

Apache Geode is a data management platform that provides a database-like
consistency model, reliable transaction processing and a shared-nothing
architecture to maintain very low latency performance with high concurrency
processing.

Geode {version} contains a number of improvements and bug fixes. It includes performance improvements in OQL order-by and distinct queries in client/server when security is enabled. New GFSH commands were added to get/set cluster config and to destroy gateway receivers. A new post processor was added to the new client protocol. Pulse now supports legacy SSL options. Auto-reconnecting members no more reuse old addresses and IDs. Duplicated or member-specific receivers are removed from cluster config during rolling upgrades. Users are encouraged to upgrade to the latest release.
For the full list of changes please review the release notes:
https://cwiki.apache.org/confluence/display/GEODE/
Release+Notes#ReleaseNotes-{version}

The release artifacts can be downloaded from the project website:
http://geode.apache.org/releases/

The release documentation is available at:
http://geode.apache.org/docs/guide/{version eg. in the format as 17 or 18 or 19}/about_geode.html

We would like to thank all the contributors that made the release possible.
Regards,
{Release Manager} on behalf of the Apache Geode team

...