...
- 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)
- 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 2 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;
- 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.
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 ===REVIEW IF THIS IS RIGHT=== 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
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%20ManagementUpdate 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.
ADD PROCESS ON HOW TO MERGE CHANGES FROM GEODE DEVELOP TO THE RELEASE BRANCH HERE
Creating the release candidate:
Accepting changes into the release branch:
Proposals to bring changes from develop to the support 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:
No Format |
---|
Hi <thread participant(s)>, thank you for bringing your concern.
Geode's release process dictates a time-based schedule to cut release branches. Once cut, the “critical fixes” rule allows critical fixes to be brought to the release branch by proposal on the dev list.
If there is consensus from the Geode community that your proposed change satisfies the “critical fixes” rule, I will be happy to bring it to the {version} release branch.
Regards
{Release Manager} |
If three +1's are received and no minus 1's, the release manage should confirm the exact commits on develop and cherry pick to the release branch using git cherry-pick -x <SHA>
then send a notification to the thread:
No Format |
---|
There appears to be consensus that this is a critical fix.
The following commit has been brought into support/{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 support branch if it causes test problems, or further discussion of the fix leads to any "minus 1"
Creating the release candidate:
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 remotes/origin/release/1.9.0 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.
dickc@lootoo:~/Workspace/geode/develop/gemfire-assembly$ git commit -p
diff --git a/gradle.properties b/gradle.properties
index de68acc..2e6a1cb 100755
--- a/gradle.properties
+++ b/gradle.properties
@@ -1,8 +1,8 @@
group = io.pivotal.gemfire
-version = 9.9.0-build.9999
+version = 9.10.0-build.9999
# Versions of this GemFire assembly, associated geode-support, and bundled greenplum jar
-geodeSupportVersion = 9.9.0+
+geodeSupportVersion = 9.10.0+
greenplumConnectorVersion = 3.+
minimumGradleVersion = 5.4
Stage this hunk [y,n,q,a,d,/,s,e,?]? y[develop cb011e4] change defaults to new version 1.10.0
1 file changed, 2 insertions(+), 2 deletions(-)Info If you are running on linux, you may see this error message:
dickc@lootoo:~/Workspace/geode/develop/gemfire-assembly$ git commit -p
diff --git a/gradle.properties b/gradle.properties
index de68acc..2e6a1cb 100755
--- a/gradle.properties
+++ b/gradle.properties
@@ -1,8 +1,8 @@
group = io.pivotal.gemfire
-version = 9.9.0-build.9999
+version = 9.10.0-build.9999
# Versions of this GemFire assembly, associated geode-support, and bundled greenplum jar
-geodeSupportVersion = 9.9.0+
+geodeSupportVersion = 9.10.0+
greenplumConnectorVersion = 3.+
minimumGradleVersion = 5.4
Stage this hunk [y,n,q,a,d,/,s,e,?]? y[develop cb011e4] change defaults to new version 1.10.0
1 file changed, 2 insertions(+), 2 deletions(-)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 remotes/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.
- Review the artifacts and revisions under build before moving in to publishing. You should see these directories
- 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
- geode-examples - The geode examples checkout. Again, check the revision
- geode-native - The geode native checkout.
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.0settings.gradle add new version to geode-old-versions.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
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
- Verify that all the artifacts have been uploaded to the nexus repository by logging into repository.apache.org and then click on close. Example:
- If there is an older geode staging repository listed (from a previous RC, make sure you drop it. Find "orgapachegeode-####" and clink on "Drop"
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"
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]
...