...
- 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 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: '' benchmark_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?group=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 (note: you must be in the Jira Administrators group to do this, ask on the dev list if you are not).
Validate Fix Versions in JIRA
Occasionally someone will have assigned the the wrong fix version to JIRA tickets. This might result in users expecting a fix or feature to be in a release when it in fact is not. To avoid confusing or misleading our users, we need to validate that a) everything that's labeled to be in this release is in fact there and vice versa that everything that is in the release, also is marked accordingly in JIRA.
Several community members have written scripts that automate at least some of those tasks in the past. To validate that every ticket has a corresponding commit, you could use this script.
Creating a Release Candidate
...