...

Also ask the community to confirm that the Geode LICENSE and NOTICE files accurately reflect what is on develop. 

Branching for release

Create the release

...

branches

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/teams/main/pipelines/apache-develop-main/jobs/UpdatePassingTokens.
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.  NoteNote: 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: '' benchmark_branch: developrelease/{version}

   
   

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 pull git checkout -b release/{version} git push origin HEAD

    
    

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

    
    

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

    
    

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

    
    

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

    
    

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

...

1. From one directory above a checkout of latest geode develop, run the prepare_rc script (a release-n.n.n-workspace dir will be created in the current directory).  This script assumes expects that there is a release/X.Y.Z branch pushed to geode, geode-examples, geode-native, and geode-examplesbenchmarks.  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.  Do not run this in a remote shell or headless environment, as a GUI is required to prompt for your GPG passphrase (several times) and your ASF LDAP password (Apache password). Do not include @apache.org in your apache username.  If your are not a PMC member, when prompted for SVN password, hit enter and get a PMC member to enter their username and password, otherwise you will not be able to make the final release later.

   Code Block
   geode/dev-tools/release/prepare_rc.sh -v 1.9.0.RC1 -k last_8_digits_of_your_gpg_key -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 finalize nexus staging (pictured below), publish the release candidate, and send the VOTE email.

3. 

...

Before giving the RC to the community to validate, make an rc pipeline to validate that the artifacts are viable and watch for all jobs to turn green:

geode/dev-tools/release/deploy_rc_pipeline.sh -v 1.9.0

...

Hello Apache Geode Community, 

It is time to update the 3rd-party libraries used by GEODE. To get that done, I am requesting a volunteer to take on the responsibility.

This consists of updates going through the libraries we depend on and updating them to the latest version that works with our code.

WeIt would needbe nice to get this done within the next week or two, so that we have time to shake out issues before the next release.

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

...