Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: More changes related to using a script for the RC

...

  1. git →  https://git-scm.com/downloads
  2. docker → https://docs.docker.com/docker-for-mac/install/ 
  3. svn → shipped with MacOS [install with command line tools → https://stackoverflow.com/questions/9329243/xcode-install-command-line-tools]
  4. gpg tools → https://gpgtools.org
  5. web browser → https://support.google.com/chrome/answer/95346?co=GENIE.Platform%3DDesktop&hl=en
  6. java JDK → https://docs.oracle.com/javase/8/docs/technotes/guides/install/install_overview.html
  7. text editor : vi → should be pre-installed
  8. Homebrew → https://brew.sh/
  9. fly → use platform-appropriate download link in bottom right corner of https://concourse.apachegeode-ci.info
  10. cmake and doxygen - install with brew on mac (brew install doxygen && brew install cmake)

Permission and keys:


Info
titlePermission and Keys:
  • Ensure that the release manager has bulk modification permissions on Apache Geode JIRA.

To verify

    1. Go to : https://issues.apache.org/jira/secure/Dashboard.jspa→ login → Issues → Search for Issues → select Geode in the Project list
    2. After logging in, on the top right side of the page click on Tools → Bulk Change → Current Page
    3. Select any ticket and click Next
    4. The Transition Issue option should not be blocked as N/A. If it is not blocked means that you have bulk operation permission.
    5. If you don't have permissions, send a mail requesting permission to dev@geode.apache.org.
  • Ensure you have permission to modify the wiki for the release docs : Release Notes
  • The release manager will need to have a Docker Hub credential that has permission to upload Apache Geode to Docker Hub. To get permissions follow the steps below
    1. If you don't have a docker hub account create one at https://hub.docker.com/
    2. After creating the docker hub ID, send an email to dev@geode.apache.org requesting access to upload Apache Geode artifacts to Docker Hub mentioning your docker id.


  • Ensure that you have a valid pgp key.
    1. For MacOS use https://gpgtools.org/
    2. For Ubuntu https://askubuntu.com/questions/100281/how-do-i-make-a-pgp-key
    3. Ensure that the public key is published and uploaded to servers.
    4. Ask a fellow committer to co-sign the keys, this ensures that the keys are available on public servers.
    5. If you are using GPG Tools >= 2.1, export your secret key to a file to be used by Gradle. You can export it with `gpg --export-secret-keys >~/.gnupg/secring.gpg`
  • Add your public key block to KEYS file in develop branch if they are not already present in it.
    1. On MacOS : (More information available at https://www.apache.org/dev/release-signing.html#basic-facts)

      Code Block
      titleOn MacOS terminal
      (gpg --list-sigs <your name> && gpg --armor --export <your name>) >> keys.log


    2. Take the contents of keys.log and append it to KEYS file in the develop branch of Apache Geode. Commit and push to origin.
    3. Also, add the key fingerprint to https://id.apache.org under OpenPGP Public Key Primary Fingerprint. The fingerprint can be found in the GPG Keychain in MacOS or the second line of the command executed in step a.
    4. Also upload your public key into keyserver
      1. http://pool.sks-keyservers.net:11371
      2. http://keyserver.ubuntu.com:11371
    5. Sample key block which needs to be appended to the KEYS file in develop:

      No Format
      pub   rsa4096 2018-01-04 [SC] [expires: 2022-01-04]
            CE6CD0A89480B1B9FCB98699274C66710770C135
      uid           [ultimate] Nabarun Nag <nag@cs.wisc.edu>
      sig 3        274C66710770C135 2018-01-04  Nabarun Nag <nag@cs.wisc.edu>
      sig 3        C8D3705F9DBE2177 2018-02-26  Jason Huynh <jasonhuynh@apache.org>
      sub   rsa4096 2018-01-04 [E] [expires: 2022-01-04]
      sig          274C66710770C135 2018-01-04  Nabarun Nag <nag@cs.wisc.edu>
      
      -----BEGIN PGP PUBLIC KEY BLOCK-----
      
      mQINBFpOogwBEADlT2Ue6XDFHqbM/LbZXhHMw4rcT4ifuBGyibbUbhLWGimav5tI
      buGRxOViV2q5FNIEYK6Gyfr1kKTlBxCZxkmbNj5lyqgBM7HfL0sTQ2kGd9IE7rPz
      KQ65yzUdKd4Aacm9Zlfja6pV6vYbMBdd4gcGFfsobh4yD0dZFXBlkEiqKV89PhxG
      h9PaBFN6FfDYTaUwir2MveV54N5ynPKcVt9Ler5v6wo/1Mr+bxoZ5dy15UMqxgHT
      YfRDGmLvCPjI0Aabc86bzgi8FJ8QdW1/oBLH/fjDardQOSgGCI7Smz4F52LGXb7Z
      .
      .
      .
      Y79TWNoe0dBLf6B8dmX+aqfWhziCz2Ijy8lF8sfQl2DalG+YpBkBBsNs8j/6lpHr
      Fgh2AddGmNuaP+tMFGCtdeHujkSbx7b1UOkxgLTS7nsRM0l6QN4czTNYcaUFgVU4
      Ig==
      =VFqr
      -----END PGP PUBLIC KEY BLOCK-----
      
      
      


...

  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
    titleCreate release branch
    git checkout -b release/{version}


  4. gradle.properties

      1. remove -SNAPSHOT in releaseType 
  5. docker/Dockerfile
      1. Update GEODE_GPG with your GPG fingerprint.
      2. Update GEODE_VERSION with the release version (eg. 1.8.0)
  6. 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
    titleUpdating 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
    languagebash
    titlegradle build
    ./gradlew clean build -Dskip.tests=true

    - Update dependency versions using gradle task updateExpectedPom.

    Code Block
    languagebash
    titlegradle uEP
    ./gradlew uEP

    - Publish the release branch to origin

    Code Block
    titlePublish the release branch
    git add .
    git commit -a -m "Upgraded version number for releasing {version}"
    pit push origin release/{version}

    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}

    Setting up concourse release pipeline

    No Format
    $ cd ci/pipelines/meta
    $ ./deploy_meta.sh
    
    # You might need fly in your PATH 
    # fly target named `concourse.apachegeode-ci.info`
    $ fly -t concourse.apachegeode-ci.info login --concourse-url https://concourse.apachegeode-ci.info/

Release Doc preparation:

...



  1. Now checkout the repo for geode-examples and create a release branch.

    Code Block
    titleCreate release branch
    git checkout develop
    git checkout -b release/{version}


  2. Update the version number in gradle.properties of geode-examples

    Code Block
    version = 1.7.0
    geodeVersion = 1.7.0


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


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


  4. Checkout the repo for geode-native and create a release branch


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


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



  6. Setting up concourse release pipeline

    No Format
    $ cd ci/pipelines/meta
    $ ./deploy_meta.sh
    
    # You might need fly in your PATH 
    # fly target named `concourse.apachegeode-ci.info`
    $ fly -t concourse.apachegeode-ci.info login --concourse-url https://concourse.apachegeode-ci.info/


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

  1. gradle.properties
      1. update versionNumber to the next release version (for example: if you created release branch for 1.8.0 update version number to 1.9.0 in the below files in develop branch)
      2. ensure that releaseType has -SNAPSHOT in it.
  2. geode

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

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

    Add the new ordinal

    Code Block
    languagejava
    titleNew ordinal
    //Add 5 to the previous ordinal
    private static final byte GEODE_190_ORDINAL = 100;

    Add the new version 

    Code Block
    languagejava
    titleAdding the new version
    public static final Version GEODE_190 =
        new Version("GEODE", "1.9.0", (byte) 1, (byte) 9, (byte) 0, (byte) 0, GEODE_190_ORDINAL);

    Set the current version to the new version

    Code Block
    languagejava
    titleSet current to new version
    public static final Version CURRENT = GEODE_190;

    Update the highest version

    Code Block
    languagejava
    titleSet current to new version
    public static final int HIGHEST_VERSION = 105;
     geode-core/src/main/java/org/apache/geode/internal/cache/tier/sockets/CommandInitializer.java

    Add the next version to addCommands

    Code Block
    languagejava
    titleCommandInitializer
    ALL_COMMANDS.put(Version.GEODE_190, commands);
  3. Update the version in geode-book/config.yml and geode-book/redirects.rb on develop.
  4. Update the expected-pom.xml files

    Info
    titleUpdating 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
    languagebash
    titlegradle build
    ./gradlew clean build -Dskip.tests=true

    - Update dependency versions using gradle task updateExpectedPom.

    Code Block
    languagebash
    titlegradle uEP
    ./gradlew uEP

    - Publish the develop branch to origin

    Code Block
    titlePublish the release branch
    git add .
    git commit -a -m "Upgraded version number for releasing 1.x.x"
    pit push origin develop

Creating the release candidate:

  1. apache/geode/internal/Version.java
      1. Add the new ordinal

        Code Block
        languagejava
        titleNew ordinal
        //Add 5 to the previous ordinal
        private static final byte GEODE_190_ORDINAL = 100;


      2. Add the new version 

        Code Block
        languagejava
        titleAdding the new version
        public static final Version GEODE_190 =
            new Version("GEODE", "1.9.0", (byte) 1, (byte) 9, (byte) 0, (byte) 0, GEODE_190_ORDINAL);


      3. Set the current version to the new version

        Code Block
        languagejava
        titleSet current to new version
        public static final Version CURRENT = GEODE_190;



      4. Update the highest version

        Code Block
        languagejava
        titleSet current to new version
        public static final int HIGHEST_VERSION = 105;


  2.  geode-core/src/main/java/org/apache/geode/internal/cache/tier/sockets/CommandInitializer.java
      1. Add the next version to addCommands

        Code Block
        languagejava
        titleCommandInitializer
        ALL_COMMANDS.put(Version.GEODE_190, commands);



  3. Update the version in geode-book/config.yml and geode-book/redirects.rb on develop.
  4. Update the expected-pom.xml files

    Info
    titleUpdating 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
    languagebash
    titlegradle build
    ./gradlew clean build -Dskip.tests=true

    - Update dependency versions using gradle task updateExpectedPom.

    Code Block
    languagebash
    titlegradle uEP
    ./gradlew uEP

    - Publish the develop branch to origin

    Code Block
    titlePublish the release branch
    git add .
    git commit -a -m "Upgraded version number for releasing 1.x.x"
    pit push origin develop



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

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

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


Creating the release candidate:

  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 and ASF LDAP password (Apache 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
    cd 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. 

    Code Block
    languagebash
    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:
    Image Added
  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"
    Image Added
  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.

  7. If you are using GPG Tools >= 2.1, export your secret key to a file to be used by Gradle. You can export it with `gpg --export-secret-keys >~/.gnupg/secring.gpg`
  8. From a checkout of geode, run the prepare_rc.sh script

    Code Block
    cd 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.

  9. Review the artifacts and revisions under build before moving in to publishing. You should see these directories
    1. geode
    2. geode-examples
    3. geode-native
    4. dist        
  10. Log in to repository.apache.org and select staging repositories. Find "orgapachegeode-####" and clink on "Drop"
    Image Removed
  11. Publish the artifacts to the nexus staging repositories.  Run this command on a machine using GUI as you will be prompted to enter PGP and ASF LDAP password (Apache 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
    languagebash
    cd build/geode
    ./gradlew  publish -Paskpass -Psigning.keyId=last_8_characters_of_your_gpg_fingerprint -Psigning.secretKeyRingFile=/Users/yourusername/.gnupg/secring.gpg
    -PmavenUsername=your_apache_ldap_username

    Publish release artifacts to ASF dist repo. 

    Code Block
    languagebash
    cd dist/dev/geode
    svn commit -m "Releasing Apache Geode {version}.RC# distribution"
  12. Verify that all the artifacts have been uploaded to the nexus repository by logging into repository.apache.org and then click on close. Example:
    Image Removed
  13. In the release branch folder tag the commit. All Release Candidates start with the number 1 eg. RC1. 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
    languagebash
    cd build/geodegit push rel/v[version_with_rc]cd ../../build/geode-examplesgit push rel/v[version_with_rc]cd ../../build/geode-nativegit push rel/v[version_with_rc]

    Now checkout the repo for geode-examples and create a release branch.

    Code Block
    titleCreate release branch
    git checkout develop
    git checkout -b release/{version}

    Update the version number in gradle.properties of geode-examples

    Code Block
    version = 1.7.0
    geodeVersion = 1.7.0
    Commit the version changes and push the release branch of geode-examples
    Code Block
    git add -p
    git commit
    git push origin HEAD

    check that gfsh is not on your path already

    Code Block
    $ gfsh
    -bash: gfsh: command not found

    In the geode-examples folder, build and run it with the apache-geode version that was uploaded to the ASF dist repo.

    Code Block
    # first build the release artifacts, specifying the RC release location and staging repository
    git clean -dxf && ./gradlew -PsignArchives -PgeodeReleaseUrl=https://dist.apache.org/repos/dist/dev/geode/{version}.RC# -PgeodeRepositoryUrl=https://repository.apache.org/content/repositories/orgapachegeode-{NNNN} build runAll
     
    #if all tests pass then continue ahead, else kindly fix the issues

    If there are no failures, then tag the release candidate in geode-examples.

    Code Block
    # then tag the release candidate commit
    cd ${GEODE_EXAMPLES_SRC}
    git config user.email "email_address_associated_with_your_gpg_key"
    git tag -s rel/v{version}.RC# -m "Release candidate # for 1.0.0"
    git push origin rel/v{version}.RC#
    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.

    Publish the examples artifacts to ASF dist repo using the folder created in step 5

    Code Block
    # then upload the release artifacts for distribution
    # go to the folder created in step 6 and copy the geode-example artifacts to it
    cd dist/dev/geode
    cp ${GEODE_EXAMPLES_SRC}/build/distributions/* {version}.RC#
    svn add {version}.RC#/apache-geode-examples-*
    svn commit -m "Adding examples to Apache Geode {version}.RC# distribution"

    Make sure you have the native client required components installed. On a Mac

    Code Block
    brew install cmake
    brew install doxygen

    Checkout geode-native from https://github.com/apache/geode-native. Then `cd` into the geode-native directory, create a build directory, configure cmake and generate the source distribution via cpack

    Code Block
    languagebash
    mkdir build
    cd build
    cmake .. -DPRODUCT_VERSION={version} -DOPENSSL_ROOT_DIR=/usr/local/Cellar/openssl/1.0.2* -DGEODE_HOME=your_geode_checkout/geode-assembly/build/install/apache-geode
    cpack -G TGZ --config CPackSourceConfig.cmake
  14. This should have generated a tar file and a corresponding checksum file. Let's sign the package:

    Code Block
    languagebash
    gpg --armor -u {key ID} -b apache-geode-native-*-src.tar.gz

    Verify that the command created a new file called `apache-geode-native-{version}-Source.tar.gz.asc`.

  15. Tag the release candidate in geode native:

    Code Block
    # then tag the release candidate commit
    cd ${GEODE_NATIVE_SRC}
    git tag -s rel/v{version}.RC# -m "Release candidate # for 1.0.0"
    git push origin rel/v{version}.RC#

    Publish the geode native artifacts to ASF dist repo using the folder created in step 5

    Code Block
    languagebash
    cd dist/dev/geode
    cp ${GEODE_NATIVE_SRC}/build/apache-geode-native-{version}* {version}.RC#
    svn add {version}.RC#/apache-geode-native-*
    svn commit -m "Adding Geode Native source distribution to Releasing Apache Geode {version}.RC# distribution"

Update the version in geode-example develop branch.

...


  1. 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
    languagebash
    cd build/geode
    git push rel/v[version

...

  1. _with_rc]
    cd ../../build/geode-examples
    git push rel/v[version_with_rc]
    cd ../../build/geode-native
    git push rel/v[version_with_rc]


Send out an email announcing the RC

...