This article contains all the steps required to release Apache Geode.
Table of Contents |
---|
Before you begin
Software dependencies
- git → https://git-scm.com/downloads
- docker → https://docs.docker.com/docker-for-mac/install/
- svn → shipped with MacOS [install with command line tools → https://stackoverflow.com/questions/9329243/xcode-install-command-line-tools]
- gpg tools → https://gpgtools.org
- web browser → https://support.google.com/chrome/answer/95346?co=GENIE.Platform%3DDesktop&hl=en
- java JDK → https://docs.oracle.com/javase/8/docs/technotes/guides/install/install_overview.html
- text editor : vi → should be pre-installed
- Homebrew → https://brew.sh/
- fly → use platform-appropriate download link in bottom right corner of https://concourse.apachegeode-ci.info
- cmake, doxygen, and openssl - install with brew on mac (brew install doxygen && brew install cmake && brew install openssl)
Permission and keys
...
Info | |||||||||
---|---|---|---|---|---|---|---|---|---|
| |||||||||
To verify
| |||||||||
Info | |||||||||
| |||||||||
Announce intent to branch
Geode cuts release branches on a time-based schedule (Monday on or after Nov 1, Feb 1, May 1, Aug 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.
...
Request developers to respond back if they are waiting to finish a JIRA issue, or feel that a particular JIRA / fix must be included in the release.
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.
Also ask the community to
...
confirm that the Geode LICENSE and NOTICE files
...
accurately reflect what is on develop.
Once this discussion comes to a conclusion and everything that is necessary for the release is present in the develop branch we start with creating the release branch.
Branching for release
Create
...
the release branch
...
- 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.
- 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
Create the release branch.
Code Block language bash git checkout develop git checkout -b release/{version}
Update the version number in
gradle.properties
(and remove-SNAPSHOT
)Update the version number in
ci/pipelines/geode-build/jinja.template.yml
Change
SNAPSHOT
to""
forSEMVER_PRERELEASE_TOKEN
inci/pipelines/meta/meta.properties
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
Review the benchmark baseline. It should be the more recent of {previous release} or
develop/highwater
.branch
should stay asdevelop
even for release branches. Note: as the release progresses, consider creating and using a dedicatedversion/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
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
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}
Update the version number in gradle.properties of geode-examples and remove -SNAPSHOT
No Format version = 1.7.0 geodeVersion = 1.7.0
- 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
- 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
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}
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
- Monitor the new release pipeline and resolve any issues that may arise.
...
Begin preparing release documentation
- Start preparing the release docs at Release Notes. Use information from all the JIRAs that were closed or resolved.
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.
...
Bump the version of the develop branch
...
You will need to checkout the develop branch of geode and geode-examples.
- update gradle.properties
- 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-RELEASE on the develop branch)
- if not a patch release, update geode-core/src/main/java/org/apache/geode/internal/Version.java
Add the new ordinal for the new version
Code Block language java title New ordinal //Add 5 to the previous ordinal private static final byte GEODE_1_9_0_ORDINAL = 100;
Add the new version
Code Block language java title Adding the new version public static final Version GEODE_1_9_0 = new Version("GEODE", "1.9.0", (byte) 1, (byte) 9, (byte) 0, (byte) 0, GEODE_1_9_0_ORDINAL);
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_9_0;
Update the highest version
Code Block language java title Set current to new version public static final int HIGHEST_VERSION = 105;
- if if not a patch release, update geode-core/src/main/java/org/apache/geode/internal/cache/tier/sockets/CommandInitializer.java
Add the next version to addCommands
Code Block language java title CommandInitializer allCommands.put(Version.GEODE_1_9_0, geode18Commands);
- Update the version in geode-book/config.yml and geode-book/redirects.rb on develop. Note: do NOT include the patch digit in
product_version_nodot
in config.yml, even for patch releases Update the expected-pom.xml files
Code Block language bash title gradle build ./gradlew clean ./gradlew build -Dskip.tests=true #note: ok if build fails expected pom test ./gradlew updateExpectedPom
Review the benchmark baseline. In theory this could be updated to the new release branch, but the
highwater
tag is preferable.See ci/pipelines/shared/jinja.variables.yml around line 19:
Code Block benchmarks: baseline_branch: develop/highwater baseline_version: '' branch: develop
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
Plus the BumpMinor task to increment the concourse version in the apache-geode concourse pipeline at:
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main?groups=Semver%20Management
(if you do not have concourse permissions to plus jobs, ask on the dev list)Update the version and geodeVersion in gradle.properties file of the geode-example develop branch to the next release version
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
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.
...
Creating a Release Candidate
Accept critical fixes to the release branch
It is expected that some stabilization work may be needed once the release branch
...
is cut.
Proposals to bring changes completed and tested fixes from develop to the support release branch may be made to the dev list. The release manager may join the conversation if needed to remind the community of the process, for example:
...
If three +1's are received and no minus 1's, the release manage 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:
No Format |
---|
There appears to be consensus that this is a critical fix. The following commit has been brought into release/{version} as the critical fix for GEODE-XXXX: git cherry-pick -x {SHA} GEODE-XXXX has been marked as 'resolved in' {version}. Regards {Release Manager} |
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 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
...
If doing RC2 or later, revert the last temporary commit from geode-examples/gradle.properties and push
Code Block language bash cd geode-examples git pull git log -1 gradle.properties git revert <SHA from above> git push
From a checkout of latest geode develop, run the prepare_rc.sh script (a build dir will be created in the current directory, so you may not want to be inside geode when you run it or IntelliJ will freak out). 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. Run this command on a machine with a GUI as you will be prompted to enter PGP passphrase several times and finally 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
The "next steps" printed out at the end of the prepare_rc script will walk you through the remaining steps to stage to nexus (pictured below), publish the release, and send an announcement email.
...
The last instruction from the prepare_rc script
will be to run the commit_rc
script. When that is complete, it will print out the contents of the email for you to send (and also copy it to your clipboard, if you have pbcopy
installed). If you need to re-generate the email for any reason, use dev-tools/release/print_rc_email.sh
. Send the email to the dev@geode.apache.org with subject "[VOTE] Apache Geode <ver>RC<rc>".
Finalizing the release
". Reviewers should be encouraged to describe what they tested, not just give a +1.
Tally the votes
After the deadline has passed, reply to the VOTE thread with a voting result summary similar to the following (use the PMC roster to determine which votes are binding):
Code Block | ||
---|---|---|
| ||
It's past the announced deadline and we have enough votes to close the vote.
Voting status
==========
+1: 3 binding votes
* Name (PMC member)
* Name (PMC member)
* Name (PMC member)
* Other Name
* Other Name
+0: zero votes
-0: zero votes
-1: zero votes
The voting meets the requirements of at least 3 PMC members with +1 votes and has the required majority of +1 votes.
Apache Geode {ver}.RC{n} passed the vote and we will finalize the release shortly.
Thanks everyone for the great work!
-{Release Manager} |
If not enough votes are received, the release manager may, at their discretion, extend the voting deadline, or close the vote and start a DISCUSS thread on whether to abandon the release or try again.
If the voting is successful, proceed to the next section. If showstopper issues were raised, create a new release candidate. If the release is to be abandoned, destroy the pipeline, release branch, and staged artifacts in nexus and svn.
Finalizing the Release
Promote the RC tag and RC staging repo
Once a Once the release candidate has been approved
cd to the release branch for apache geode and tag the commit with the final version
Code Block git tag -s rel/v{version} -m "Apache Geode v1.0.0 release" rel/v{version}.RC{latest_rc} git push origin rel/v{version}
cd to the release branch for geode-examples and tag the commit with the final version, using same commands as above
cd to the release branch for geode-native and tag the commit with the final version, using same commands as above
Use svn to move the distributions from dev to release. Use the folders created in step 1 of "Creating the release candidate" section.
Code Block # in the directory created in step 1 of "Creating the release candidate" section. cd dist svn mv dev/geode/{version}.RC#/ release/geode/{version} svn commit -m "Releasing Apache Geode {version} distribution"
Update the keys in dist/release.
Code Block # in the directory created in step 1 of "Creating the release candidate" section. cp dev/geode/KEYS release/geode/KEYS svn commit -m "Updating Apache Geode KEYS file"
- Promote the Nexus staging repo → login to repository.apache.org→ Select Staging repositories → Find "orgapachegeode-####" → Click on the Release Button on the toolbar.
Revert the temporary commit from geode-examples/gradle.properties and push
Code Block language bash cd geode-examples git pull git log -1 gradle.properties git revert <SHA from above> git push
...
Transition JIRA issues fixed in this release from Resolved → Closed
Mark the version as released in Jira: go to https://issues.apache.org/jira/projects/GEODE?selectedItem=com.atlassian.jira.jira-projects-plugin:release-page and click on the ... to get the Actions pop-up menu and click Release.
- List all the JIRAs with fix version as the release version and status as resolved.
Using bulk operations → transition to closed state.
Wait for mirror sites to sync
*** 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 below docker and brew and announce steps depend on most or all mirrors being up-to-date.***
Upload the docker image to
...
dockerhub
- docker/Dockerfile
- Update GEODE_GPG with your GPG fingerprint.
- Update GEODE_VERSION with the release version (eg. 1.8.0)
- Update GEODE_SHA256 with the SHA from https://dist.apache.org/repos/dist/release/geode/{VERSION}/apache-geode-{VERSION}.tgz.sha256 (Replace VERSION with the version you are trying to release).
- Check these changes in to the release branch. If for some reason you have already merged the release branch to master and deleted it, check the changes in to master.
- Follow the instruction present in docker/README.md
- Note that you may see a 404 error during the docker build process, because it tries a mirror first before falling back to the primary download site, and some mirror sites take 8-24 hours to sync. As long as the docker build completes successfully you're ok.
...
No Format |
---|
fly -t concourse.apachegeode-ci.info login --concourse-url https://concourse.apachegeode-ci.info/ cd ci/pipelines/meta ./destroy_pipelines.sh |
Merge to master and destroy release
...
branches
Merge release branch to master for apache geode and then delete the release branch
Code Block git fetch --all git checkout release/1.9.0 git merge -s ours origin/master -m "Merging release/1.9.0 into master" git checkout master git merge release/1.9.0 git push origin master git branch -D release/{version} git push origin --delete release/{version}
Merge release branch to master for geode-examples and then delete the release branch, using same commands as above
- Merge release branch to master for geode-native and then delete the release branch, using same commands as above
...
It's a good idea to make a PR for this rather than committing directly, since these changes affect tests!
...
Send the announce mail
...
To: user@geode.apache.org, announce@apache.org, dev@geode.apache.org
...
No Format |
---|
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 |
Remove previous release from mirrors
...
remove from apache mirrors
Code Block cd dist/release/geode svn rm {$old_release} svn commit -m "remove old releases (they can still be found at http://archive.apache.org/dist/geode)"
- update https://geode.apache.org/releases/
- change the links (for old versions only, not the one you just released!) that contain closer.cgi to archive, like this:
- before: http://apache.org/dyn/closer.cgi/geode...
- after: http://archive.apache.org/dist/geode...
- change the links for the gpg/md5 links like this:
- before: https://www.apache.org/dist/geode...
- after: https://archive.apache.org/dist/geode...
- change the links (for old versions only, not the one you just released!) that contain closer.cgi to archive, like this:
Update dependencies
Immediately after release is the best time to bump dependency versions on the various 3rd-party libraries used by Geode. Start a DISCUSS thread asking for a volunteer to lead this effort.