Page History

...

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 in JIRA, that all tickets with {version} as the fix version are either closed or resolved. If not inform the the assignees to either resolve/close it or if not fixed then increment the fix version in the ticket

3. Create the release branch.

   Code Block
   title Create release branch
   git checkout -b release/{version}

   
   

4. gradle.properties

   1. 1. remove -SNAPSHOT in version (ie. 1.10.0-SNAPSHOT to 1.10.0)

5. Update the version number in all the expected pom files. Doing it manually takes a lot of time. If you choose to do it I have listed the files below. Otherwise please use the script below to do it.

   Info
   title Updating the expected-pom files
   - build geode after the version is updated in gradle.properties. NOTE: The build will fail but will have the correct expected-pom.xml files Code Block language bash title gradle build ./gradlew clean build -Dskip.tests=true - Update dependency versions using gradle task updateExpectedPom. Code Block language bash title gradle uEP ./gradlew uEP - Publish the release branch to origin Code Block title Publish the release branch git add . git commit -a -m "Upgraded version number for releasing {version}" pit push origin release/{version}

   
   

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

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

   
   

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

   Code Block
   version = 1.7.0 geodeVersion = 1.7.0

   
   

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

   
   

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

   
   

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

   
   

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

   
   

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

    
    

    
    

11. Setting up concourse release pipeline

    No Format
    fly -t concourse.apachegeode-ci.info login --concourse-url https://concourse.apachegeode-ci.info/ Remove SNAPSHOT from SEMVER_PRERELEASE_TOKEN in meta.properties cd ci/pipelines/meta ./deploy_meta.sh

    
    

12.  Monitor the new release pipeline that the above creates and resolve any issues that may arise. 

Release Doc preparation:

1. Start preparing the release docs at Release Notes. Use information from all the JIRAs that were closed or resolved. 

2. Also write up a short paragraph on what was added to the release. This will need to go with the final announce email. Sample:

   
   

   No Format

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

   
   

Prepare develop branch for the next release

You will need checkouts of geode, geode-example and geode-benchmarks

1. gradle.properties
   1. 1. update versionNumber update the version property to the next release version and ensure that it has -SNAPSHOT on the end. (for example: if you created release branch for 1.8.0 update version number to 1.9.0 in the below files in -RELEASE on the develop branch)
      2. ensure that releaseType has -SNAPSHOT in it.
2. geode-core/src/main/java/org/apache/geode/internal/Version.java
   

   1. 1. Add the new ordinal for the new version

         Code Block
         language java title New ordinal
         //Add 52 to the previous ordinal private static final byte GEODE_1901_9_0_ORDINAL = 100;

         
         

      2. Add the new version 

         Code Block
         language java title Adding the new version
         public static final Version GEODE_1901_9_0 = new Version("GEODE", "1.9.0", (byte) 1, (byte) 9, (byte) 0, (byte) 0, GEODE_1_1909_0_ORDINAL);

         
         

      3. Set the current version to the new version

         Code Block
         language java title Set current to new version
         public static final Version CURRENT = GEODE_1_1909_0;

         
         
         

      4. Update the highest version

         Code Block
         language java title Set current to new version
         public static final int HIGHEST_VERSION = 105;

         
         

3.  geode-core/src/main/java/org/apache/geode/internal/cache/tier/sockets/CommandInitializer.java

   1. 1. Add the next version to addCommands

         Code Block
         language java title CommandInitializer
         ALL_COMMANDSallCommands.put(Version.GEODE_1901_9_0, commandsgeode18Commands);

         
         

         
         

4. Update the version in geode-book/config.yml and geode-book/redirects.rb on develop.

5. Update the expected-pom.xml files

   Info
   title Updating the expected-pom files
   - build geode after the version is updated in gradle.properties. NOTE:The build will fail but will have the correct pom-default.xml files Code Block language bash title gradle build ./gradlew clean build -Dskip.tests=true - Update dependency versions using gradle task updateExpectedPom. Code Block language bash title gradle uEP ./gradlew uEP Update the benchmark baseline to the new release branch. E.g. in ci/pipelines/shared/jinja.variables.yml around line 59: Code Block set baseline_branch: "release/1.10.0" set baseline_version: "" - Publish the develop branch to origin Code Block title Publish the changes to develop git add . git commit -a -m "Upgraded version number for releasing 1.x.x" pit push origin develop

   Update the benchmark baseline to the release branch you just created.

   E.g. in ci/pipelines/shared/jinja.variables.yml around line 59:

   Code Blockset baseline_branch: "release/1.10.0" set baseline_version: ""

   version number for releasing 1.x.x" pit push origin develop

   
   

6. Bump the minor version on the apache-geode pipeline at: https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main?groups=Semver%20Management

7. Update the version in geode-example develop branch.

   Update the version in gradle.properties to the next release's snapshot

   Code Block
   language bash
   git checkout develop version = 1.9.0-SNAPSHOT geodeVersion = 1.9.0-SNAPSHOT git add -p git commit git push origin HEAD

   
   

8. In Jira, add new version of develop: go to https://issues.apache.org/jira/projects/GEODE?selectedItem=com.atlassian.jira.jira-projects-plugin:release-page and fill in the new version and click Add.

...

1. From a checkout of geode, run the prepare_rc.sh script. Run this command on a machine using GUI as you will be prompted to enter PGP key password. You will see messages like "Could not find metadata org.apache.geode:geode-cq/maven-metadata.xml" on your terminal. Ignore them.

   Code Block
   cdremotes/origin/release/1.9.0cd dev-tools/release ./prepare_rc.sh -v version_with_rc -k your_8_digit_key_id

   
   

   This script assumes there is a release/X.Y.Z branch pushed to all of the geode repositories (geode, geode-native, geode-examples). It will checkout the tip of that branch for all repos, build them, and copy the artifacts to the build/dist directory. It will also tag the RC in each checkout.

   Info
   If you are running on linux, you may see this error message: error: gpg failed to sign the data error: unable to sign the tag  If you get that error message, try to sign some random file so that gpg will unlock your keyring. After that the git tag -s should work.

   
   

2. Review the artifacts and revisions under build before moving in to publishing. You should see these directories
   1. geode - This is your geode checkout. It should have a tag for your release, eg rel/v.1.9.0.RC4. Make sure that the revision that was built is correct
   2. geode-examples - The geode examples checkout. Again, check the revision
   3. geode-native - The geode native checkout.

   4. dist   - This is an svn checkout of apache's staging area. It will have artifacts added, but not committed. Review the added artifacts. You should see something like this:

      Code Block

      dist> svn status A dev/geode/1.9.0.RC5 A dev/geode/1.9.0.RC5/apache-geode-1.9.0-src.tgz A dev/geode/1.9.0.RC5/apache-geode-1.9.0-src.tgz.asc A dev/geode/1.9.0.RC5/apache-geode-1.9.0-src.tgz.sha256 A dev/geode/1.9.0.RC5/apache-geode-1.9.0.tgz A dev/geode/1.9.0.RC5/apache-geode-1.9.0.tgz.asc A dev/geode/1.9.0.RC5/apache-geode-1.9.0.tgz.sha256 A dev/geode/1.9.0.RC5/apache-geode-examples-1.9.0.tar.gz A dev/geode/1.9.0.RC5/apache-geode-examples-1.9.0.tar.gz.asc A dev/geode/1.9.0.RC5/apache-geode-examples-1.9.0.tar.gz.sha256 A dev/geode/1.9.0.RC5/apache-geode-examples-1.9.0.zip A dev/geode/1.9.0.RC5/apache-geode-examples-1.9.0.zip.asc A dev/geode/1.9.0.RC5/apache-geode-examples-1.9.0.zip.sha256 A dev/geode/1.9.0.RC5/apache-geode-native-1.9.0-src.tar.gz A dev/geode/1.9.0.RC5/apache-geode-native-1.9.0-src.tar.gz.asc A dev/geode/1.9.0.RC5/apache-geode-native-1.9.0-src.tar.gz.sha512

      
      

3. If everything looks good, publish the artifacts to the nexus staging repositories. You will be prompted to enter your ASF LDAP password (Apache password)

   Code Block
   language bash
   cd build/geode ./gradlew publish -Paskpass -Psigning.keyId=last_8_characters_of_your_gpg_fingerprint -Psigning.secretKeyRingFile=${HOME}.gnupg/secring.gpg -PmavenUsername=your_apache_ldap_username

   
   

4. Verify that all the artifacts have been uploaded to the nexus repository by logging into repository.apache.org and then click on close. Example:
   
5. If there is an older geode staging repository listed (from a previous RC, make sure you drop it. Find "orgapachegeode-####" and clink on "Drop"
   

6. Publish release artifacts to ASF dist repo. The prepare_rc.sh script should have already added artifacts in dist/dev/geode/full_version_with_rc.

   Code Block
   language bash
   cd dist/dev/geode svn commit -m "Releasing Apache Geode {version}.RC# distribution"

   
   

7. Push the release tags. These were already created (but not pushed) by the prepare_rc.sh script. Be careful as `rel/` folder is protected, once we push the release tag to server, it cannot be modified. Any other change will have to be moved to the next RC number.

   Code Block
   language bash
   cd build/geode git push rel/v[version_with_rc] cd ../../build/geode-examples git push rel/v[version_with_rc] cd ../../build/geode-native git push rel/v[version_with_rc]

   
   

...