...
Info | |||||||||
---|---|---|---|---|---|---|---|---|---|
| |||||||||
To verify
|
Minor vs Patch release
A minor release is a version x.y.0
A patch release is a version x.y.n
where n
> 0
Except where noted, all instructions in this guide apply to both types of releases.
Announce intent to branch (minor only)
Geode cuts release support branches for new minor releases on a time-based schedule (Monday on or after Feb 1, May 1, Aug 1, Nov 1). About a week before, send a [DISCUSS] email to dev@geode.apache.org informing developers that a new release support branch is about to be created. Remind the community that only critical fixes will be allowed once the release support branch is created, so it is helpful to have develop as stable as possible before branching.
Confirm that the Geode LICENSE and NOTICE files accurately reflect what is on develop (ask for help on the dev list if you are not sure how to confirm this).
Note: patch release(s) are made only by proposal on the dev list (not on a time-based schedule), from existing support branch(es).
Branching for releaseBranching for release
Create the
...
support branches
...
(minor only)
From one directory above a checkout of latest geode develop, run the
create_support_branches
script. This will create branches on all projects and update version numbers appropriately, and guide you though creating the support pipeline, updating Jira, and creating a PR to bumpdevelop
to the next version.Code Block language bash cd .. geode/dev-tools/release/create_support_branches.sh -v 1.13 -g your_github_username
Review the benchmark baseline on the support branch. It should be the more recent of {previous release} or
develop/highwater
. Note: as the release progresses, consider creating and using a dedicatedversion/highwater
tag on the support branch.See ci/pipelines/shared/jinja.variables.yml around line 19:
Code Block language yml benchmarks: baseline_branch: develop/highwater baseline_version: '' benchmark_branch: support/{x.y}
Send email to dev@geode.apache.org informing the creation of the support branch and requesting feedback.
No Format Hello Geode Dev Community, We have created a new support branch for Apache Geode {x.y.0} - "support/{x.y}" We hope to make a final release in about a month. Please focus your acceptance testing on this branch and raise any concerns in the next few weeks. After some quiet period we will package a release candidate and begin voting upon it. Regards {Release Manager}
For the duration of the release process, continue to monitor the new release pipeline and address any issues that may arise, including analyzing any test failures.
Bump the version of the develop branch (minor only)
The
create_support_branches
script already walked you through creating the PR for this, adding the new version to Jira, and bumping the pipeline version on develop. (note: you must be in the Jira Administrators group to see the Add button in Jira; request permission on the dev list if you don't see it).Review the benchmark baseline on develop. Ask on the dev list if you are unsure whether the last support branch or a
highwater
tag makes the most sense- 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/teams/main/pipelines/apache-develop-main/jobs/UpdatePassingTokens.
Update the version number in
gradle.properties
(and remove-SNAPSHOT
)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
- Update JAR name used in org/apache/geode/session/tests/Tomcat8ClientServerRollingUpgradeTest.java
Remove `-SNAPSHOT` from the following lines:
Code Block language yml "/lib/geode-modules-" + currentVersion + "-SNAPSHOT.jar", "/lib/geode-modules-tomcat8-" + currentVersion + "-SNAPSHOT.jar",
the resulting change will look like:
Review the benchmark baseline. It should be the more recent of {previous release} orCode Block language yml "/lib/geode-modules-" + currentVersion + ".jar", "/lib/geode-modules-tomcat8-" + currentVersion + ".jar",
develop/highwater
. 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:
languageCode Block yml benchmarks: baseline_branch: develop/highwater baseline_version: '' benchmark_branch: release/{version}
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 #very important--a fresh clone of examples gives you master! git pull git checkout -b release/{version}
Update the version number in gradle.properties of geode-examples and remove -SNAPSHOT
Commit the version changes and push the release branch of geode-examplesNo Format version = 1.7.0 geodeVersion = 1.7.0
Checkout the repo for geode-native (apache/geode-native.git) and create a release branchCode Block language bash git add -p git commit git push origin HEAD
Checkout the repo for geode-benchmarks (apache/geode-benchmarks.git) and create a release branchCode Block language bash git checkout develop git pull git checkout -b release/{version} git push origin HEAD
Code Block language bash git checkout develop git pull 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}" We hope to make a final release in about a month. Please focus your acceptance testing on this branch and raise any concerns in the next few weeks. After some quiet period we will move to formally package a release candidate and vote upon it. Regards {Release Manager}
Create the concourse release pipeline.
Code Block language bash fly -t concourse.apachegeode-ci.info-main login --concourse-url https://concourse.apachegeode-ci.info/ cd ci/pipelines/meta ./deploy_meta.sh
This script takes 1-2 hours. There is no need to manually unpause any jobs. If the script fails at any point, or any
-meta
or-images
pipeline job fails, fix the problem (if applicable) and rerun./deploy_meta.sh
to try again. Repeat untildeploy_meta
exits with "Successfully deployed
...-main
"- For the duration of the release process, continue to monitor the new release pipeline and address any issues that may arise, including analyzing any test failures.
Create the release branch (from HEAD should be fine, or if necessary you can specify a particular SHA, such as the last commit that passed the develop pipeline successfully)
Code Block | ||
---|---|---|
| ||
git checkout develop
git checkout -b release/{version} [GOOD_SHA] |
Bump the version of the develop branch
You will need to checkout the develop branch of geode and geode-examples.
...
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)
...
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 see the Add button; request permission on the dev list if you don't see it).
...
- 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
...
update the metadata initial_version property to the next release version
Code Block | ||||
---|---|---|---|---|
| ||||
metadata:
initial_version: 1.13.0 |
...
Add the new ordinal for the new version
Code Block | ||||
---|---|---|---|---|
| ||||
//Add 5 to the previous ordinal
private static final byte GEODE_1_13_0_ORDINAL = 120; |
Add the new version
Code Block | ||||
---|---|---|---|---|
| ||||
public static final Version GEODE_1_13_0 =
new Version("GEODE", "1.13.0", (byte) 1, (byte) 13, (byte) 0, (byte) 0, GEODE_1_13_0_ORDINAL); |
Set the current version to the new version
Code Block | ||||
---|---|---|---|---|
| ||||
public static final Version CURRENT = GEODE_1_13_0; |
Update the highest version
Code Block | ||||
---|---|---|---|---|
| ||||
public static final int HIGHEST_VERSION = 120; |
...
Add the next version to addCommands
Code Block | ||||
---|---|---|---|---|
| ||||
allCommands.put(Version.GEODE_1_13_0, geode18Commands); |
...
Update the expected-pom.xml files
Code Block | ||||
---|---|---|---|---|
| ||||
./gradlew clean
./gradlew build -Dskip.tests=true #note: ok if build fails expected pom test
./gradlew updateExpectedPom |
Review the benchmark baseline. Ask on the dev list if you are unsure whether the last release branch or a highwater
tag makes the most sense.
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 | ||
---|---|---|
| ||
git add .
git commit -a -m "Upgraded version number for releasing 1.x.x"
pit push origin develop |
Update the version and geodeVersion in gradle.properties file of the geode-example develop branch to the next release version
Code Block | ||
---|---|---|
| ||
git checkout develop
version = 1.9.0-SNAPSHOT
geodeVersion = 1.9.0-SNAPSHOT
git add -p
git commit
git push origin HEAD |
Validate Fix Versions in JIRA
There are two parts to this audit:
- Does every commit since the last release branch have a corresponding Jira ticket marked as Fixed in this version?
- Can every Jira ticket marked as fixed in this version be traced to a commit in this release branch?
To help automate the process of identifying commits and tickets in need of review, you may find this script useful, or create your own script.
Tips:
- If a Jira ticket is fixed on develop AND cherry-picked to a release branch, it should list both fix versions.
- If a Jira ticket is fixed by way of another commit or Jira ticket, there should be a comment detailing this.
- If a Jira ticket is partially fixed but there is more work to be done in the next release, splitting into two tickets may be the best way to represent that.
- Don't forget about geode-native. It's a separate git repository but uses GEODE Jira tickets and is released as part of Geode.
- Be mindful of revert commits
- Be mindful of Jira tickets resolved as "Won't Fix", "Duplicate" etc.
- Be mindful of Jira tickets that were re-opened, but the Fixed version was never cleared.
- For changes that came in close to the time a release branch was cut, double-check whether the fix actually made it onto the branch. The list of release start dates can be helpful, but checkout the release tag to confirm for certain.
- When in doubt, reach out to people that have been involved the with ticket to confirm its status. Many times they just forgot to marked it fixed when their PR got merged, or forgot to fill in the fixed version.
Begin preparing release documentation
...
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. |
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 completed and tested fixes from develop to the 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:
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 manager 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 monitor and 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
From one directory above a checkout of latest geode develop, run the prepare_rc script (a release-n.n.n-workspace dir will be created in the current directory). This script expects that there is a release/X.Y.Z branch pushed to geode, geode-examples, geode-native, and geode-benchmarks. It will checkout the tip of that branch for all repos, build them, and prepare the artifacts. It will also prepare RC tags in each repository and finally pre-stage to nexus. Do not run this in a remote shell or headless environment, as a GUI is required to prompt for your GPG passphrase (several times) and your ASF LDAP password (Apache password). Do not include @
apache.org
in your apache username. If your are not a PMC member, when prompted for SVN password, hit enter and get a PMC member to enter their username and password, otherwise you will not be able to make the final release later.
Code Block |
---|
geode/dev-tools/release/prepare_rc.sh -v 1.9.0.RC1 -k last_8_digits_of_your_gpg_key -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 finalize nexus staging (pictured below), publish the release candidate, and send the VOTE email.
...
develop
Validate Fix Versions in JIRA
There are two parts to this audit:
- Does every commit since the last release have a corresponding Jira ticket marked as Fixed in this version?
- Can every Jira ticket marked as fixed in this version be traced to a commit in this support branch since the last release?
To help automate the process of identifying commits and tickets in need of review, you may find this script useful, or create your own script.
Tips:
- If a Jira ticket is fixed on develop AND cherry-picked to a support branch, it should list both fix versions.
- If a Jira ticket is fixed by way of another commit or Jira ticket, there should be a comment detailing this.
- If a Jira ticket is partially fixed but there is more work to be done in the next release, splitting into two tickets may be the best way to represent that.
- Don't forget about geode-native. It's a separate git repository but uses GEODE Jira tickets and is released as part of Geode.
- Be mindful of revert commits
- Be mindful of Jira tickets resolved as "Won't Fix", "Duplicate" etc.
- Be mindful of Jira tickets that were re-opened, but the Fixed version was never cleared.
- For changes that came in close to the time a support branch was cut, double-check whether the fix actually made it onto the branch. The list of release start dates can be helpful, but checkout the release tag to confirm for certain.
- When in doubt, reach out to people that have been involved the with ticket to confirm its status. Many times they just forgot to marked it fixed when their PR got merged, or forgot to fill in the fixed version.
Begin preparing release documentation
- Start preparing the release docs at Release Notes. Ask the community for suggestions on fixes and features to highlight, or go through the commits yourself and choose 5-10 items of interest.
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.13.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.
Creating a Release Candidate
Accept critical fixes to the support branch
It is expected that some stabilization work may be needed once the support branch is cut.
Proposals to bring completed and tested fixes 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 (omit the time-based part if this is a patch release):
No Format |
---|
Hi <thread participant(s)>, thank you for bringing your concern.
Geode's release process dictates a time-based schedule to cut support branches. Once cut, the “critical fixes” rule allows critical fixes to be brought to the support 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 support/{x.y} branch.
Regards
{Release Manager} |
If three +1's are received and no minus 1's, the release manager should:
- confirm that the ticket is already in a resolved state on develop
- confirm the exact commits on develop
- cherry pick to the support 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 support 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 support/{x.y} as the critical fix for GEODE-XXXX:
git cherry-pick -x {SHA}
I have marked GEODE-XXXX as also 'resolved in' {x.y.z} in Jira.
Regards
{Release Manager} |
No minimum voting period is required to bring a critical fix; it can be merged immediately upon getting 3 +1's. However, the release manager should monitor and revert it from the support branch if it causes test problems, or further discussion of the fix leads to any "minus 1".
Create the release candidate
From one directory above a checkout of latest geode develop, run the
prepare_rc script
(a release-n.n.n-workspace dir will be created in the current directory). The support branch should already exist at this point. This script will do a fresh checkout of the support branch for all repos, build them, and prepare the artifacts. It will also prepare RC tags in each repository and finally pre-stage to nexus. Do not run this in a remote shell or headless environment, as a GUI is required to prompt for your GPG passphrase (several times) and your ASF LDAP password (Apache password). Do not include@
apache.org
in your apache username. If your are not a PMC member, when prompted for SVN password, hit enter and get a PMC member to enter their username and password, otherwise you will not be able to make the final release later.Code Block geode/dev-tools/release/prepare_rc.sh -v 1.13.0.RC1 -k last_8_digits_of_your_gpg_key -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 finalize nexus staging (pictured below), publish the release candidate, and send the VOTE email.
If there is an older geode staging repository listed (from a previous RC, make sure you drop it. Find "orgapachegeode-####" and click on "Drop"
Sanity Checks
- As instructed by
commit_rc
, before giving the RC to the community to validate, make anrc
pipeline to validate that the artifacts are viable:
Code Block | ||
---|---|---|
| ||
geode/dev-tools/release/deploy_rc_pipeline.sh -v 1.13.0 |
2. wait for all jobs to turn green
3. In the next step will send an email...be sure to click EVERY link in the email before sending!
Send out an email announcing the RC
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 geode/dev-tools/release/print_rc_email.sh
. Validate (visit) all links, then send the email to the dev@geode.apache.org with subject "[VOTE] Apache Geode <ver>RC<rc>".
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 any staged artifacts in nexus and svn.
Finalizing the Release
Promote the release candidate to official release
Once a release candidate has been approved:
- Click 'Release' in http://repository.apache.org/ (pictured below step 5)
- Fork https://github.com/Homebrew/homebrew-core
- Make sure you can run
docker
info
anddocker
images
. If you are on Linux, you may first need to do: sudo groupadd docker && sudo usermod -aG docker $USER From the same directory you ran the previous release scripts, run the promote_rc script (note: you must be a Geode PMC member to commit to dist/release/geode):
Code Block geode/dev-tools/release/promote_rc.sh -v 1.13.0.RC1 -k 'your_40_digit_gpg_key' -g your_github_username
- The "next steps" printed at the end of the promote_rc script will walk you through the remaining tasks to validate the docker image, update Jira, wait overnight for mirrors to sync, make the brew PR, then finalize the release.
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
- Click on the
...
to get the Actions pop-up menu - While you're in there, add the next release (i.e. if you are releasing x . y . n, add x . y . n+1)
- Click Release (note: you must be in the Jira Administrators group to do this, ask on the dev list if you are not).
Transition JIRA issues fixed in this release from Resolved → Closed
- List all the JIRAs with fix version as the release version and status as resolved.
- Using bulk operations → transition to closed state.
If there is an older geode staging repository listed (from a previous RC, make sure you drop it. Find "orgapachegeode-####" and click on "Drop"
Sanity Check
Before giving the RC to the community to validate, make an rc
pipeline to validate that the artifacts are viable and watch for all jobs to turn green:
Code Block | ||
---|---|---|
| ||
geode/dev-tools/release/deploy_rc_pipeline.sh -v 1.9.0 |
Send out an email announcing the RC
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 geode/dev-tools/release/print_rc_email.sh
. Send the email to the dev@geode.apache.org with subject "[VOTE] Apache Geode <ver>RC<rc>".
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 release candidate to final release
Once a release candidate has been approved:
...
From the same directory you ran the previous release scripts, run the promote_rc script (note: you must be a Geode PMC member to commit to dist/release/geode):
Code Block |
---|
geode/dev-tools/release/promote_rc.sh -v 1.9.0.RC1 -k 'your_40_digit_gpg_key' -g your_github_username |
...
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
- Click on the ... to get the Actions pop-up menu
- Click Release (note: you must be in the Jira Administrators group to do this, ask on the dev list if you are not).
Transition JIRA issues fixed in this release from Resolved → Closed
...
Wait for mirror sites to sync
*** this is a good time to call it a day...mirrors take overnight to sync the new release ***
Finalize the release
Confirm that your brew PR has been closed and brew install apache-geode
picks up the new release.
Code Block |
---|
brew install apache-geode
gfsh version |
...
Code Block |
---|
geode/dev-tools/release/finalize_release.sh -v 1.9.0 -g {github-username} |
The "next steps" printed out at the end of the finalize_release script will walk you through the remaining steps update mirror links, publish docs site, and send the official release announcement.
Publish javadocs and documentation to the website
Ask on the dev list if you need help with these steps.
Update links to previous releases that appear on Keep only the latest patch release of each of the 3 most recent minors (including the one you're about to release) on https://geode.apache.org/releases/
- Build website from sources as described in geode-site/website/. The finalize_release script may have removed some old version from the mirror site, if so, the links on the "downloads" web page should be changed to point to the archive site instead, i.e.
- change the links for any old versions removed by finalize_release.sh that contain
closer.cgi
toarchive
, e.g.:- before: http://apache.org/dyn/closer.cgi/geode...
- after: http://archive.apache.org/dist/geode...
- change the .asc/.sha256 links like this:
- before: https://www.apache.org/dist/geode...
- after: https://archive.apache.org/dist/geode...
- change the links for any old versions removed by finalize_release.sh that contain
- Build website from sources as described in geode-site/website/README.md.
- In the generated site, create the directory geode-site/content/releases/latest.
- Obtain a copy of the javadoc directory from the binary release and put it in the geode-site/content/releases/latest directory (link from the website's Docs landing page points to ../releases/latest/javadoc). Deploy the generated site by checking it into the asf-site branch of the apache-geode repo.
...
- README.md.
- In the generated site, create the directory geode-site/content/releases/latest.
- Obtain a copy of the javadoc directory from the binary release and put it in the geode-site/content/releases/latest directory (link from the website's Docs landing page points to ../releases/latest/javadoc).
- Deploy the generated site by checking it into the asf-site branch of the apache-geode repo.
Wait for mirror sites to sync
*** this is a good time to call it a day...mirrors take overnight to sync the new release ***
Don't forget to finish the remaining "Next steps" from promote_rc
in the morning.
Final checks
Confirm that your brew PR has been merged or closed and
brew install apache-geode
picks up the new release.Code Block brew install apache-geode gfsh version
- Check that docs for the version you are releasing appear on https://geode.apache.org/docs/
- Check that download detail for the version you are releasing appear on https://geode.apache.org/releases/
- Check that the release has propagated to Maven Central. Sometimes this may take a couple days, it seems? Two ways to do this are:
- Check for the version you are releasing to appear on https://mvnrepository.com/artifact/org.apache.geode/geode-core
- Plus the Examples pipeline for your support branch (e.g. at https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-13-examples)
Ask for a volunteer to update dependencies
Now is the best time to bump dependency versions on the various 3rd-party libraries used by Geode. To do that, we need to Start a DISCUSS thread asking for a volunteer to lead this effort.
...
Subject: [ANNOUNCE] Apache Geode 1.913.0
*** Important: Send the email from your apache email ID*** (otherwise announce@apache.org will bounce. See https://reference.apache.org/committer/email for how to send email from your apache email address)
...