...
The Release Manager will set the rules for backporting changes to the support branch. For example, they may stipulate critical fixes only and/or require a dev list proposal and/or require a PR against the support branch and/or require a label to be added in Jira. In all cases, fixes need to be made on develop first, then backported.
Propose a release candidate (RC)
By some method, determine when all fixes are in. This might involve one or more of:
...
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 ask 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.
...
- As instructed by
commit_rc
, before giving the RC to the community to validate, make anrc
pipeline to validate that the artifacts are viable (do this in a separate terminate terminal window as it can be quite verbose):
...
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
.
Be sure to click on EVERY Click on every link to validate (especially release notes!), then send the email to the dev@geode.apache.org with subject "[VOTE] Apache Geode <ver>.RC<n>".
The voting deadline must should be at least 72 hours in the future and preferably (typically 3pm 5 days or more hence if there is a weekend). For emergency patch releases, an expedited voting deadline of as little as 24 hours may be used.
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):
...
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 (shipping) the Release
Promote the release candidate to official release
...
- Click 'Release' in http://repository.apache.org/ (pictured below step 57)
- Fork Make sure you have forked https://github.com/Homebrew/homebrew-core (click the
Fork
button in top-right corner) - Make sure you have forked https://github.com/apache/geode-native
- Make sure you have forked https://github.com/apache/geode
- Make Make sure you can run
docker
info
anddocker
images
. On Linux, you may need to addsudo
before each docker command in the promote_rc script .and/orsudo 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 svn commit to dist/release/geode):
Code Block geode/dev-tools/release/promote_rc.sh -v 1.13.0.RC1 -k last_8_digits_of_your_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, make the brew PR, then finalize the release.
, followed by the contents of the announce email (also copied to your clipboard, if you havepbcopy
installed). You can also (re)generate the email later usinggeode/dev-tools/release/print_announce_email.sh
. It's ok to start on the steps below while you are waiting for promote_rc to finish.
Mark the version as released in 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 for the version you are releasing - Click Release (note: you must be in the Jira Administrators group to do this, ask on the dev list if you are not).
- While you're in there, add the next patch release (i.e. if you are releasing x . y . n, add x . y . n+1)
...
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/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, and sometimes days for mavencentral ***
Don't forget to finish the remaining "Next steps" from promote_rc
in the morning.
Final checks
Final checks
(note(note: These steps are also covered by the "Next Final steps" from printed at the end of promote_rc
)
Confirm that your brew PR has been merged or closed and
brew install apache-geode
picks up the new release. . Note: this may take overnight...no need to hold the release announcement just for brew.Code Block brew
Code Block brew uninstall apache-geode 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 tag appears as "Verified" in https://github.com/apache/geode/tags (if not, see last step in Permissions and Keys)
- Check that the release has propagated to Maven Central. Sometimes this may take a couple days, it seems? Two ways to check 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 on develop (major/minor only)
Now is the best time to bump dependency versions on develop for the various 3rd-party libraries used by Geode. Start a DISCUSS thread asking for a volunteer to lead this effort.
Subject: [DISCUSS] Volunteer to update 3rd-party libraries used by GEODE
Ask for a volunteer to update dependencies on develop (major/minor only)
Now is the best time to bump dependency versions on develop for the various 3rd-party libraries used by Geode. Start a DISCUSS thread asking for a volunteer to lead this effort.
Subject: [DISCUSS] Volunteer to update 3rd-party libraries used by GEODE
No Format |
---|
Hello Apache Geode Community,
It's time to update the 3rd-party libraries used by GEODE. We need a volunteer to take on this responsibility.
https://github.com/apache/geode/blob/develop/dev-tools/dependencies/README.md describes how to carry out this task.
It would be awesome to get this done within the next few weeks, to allow plenty of time to shake out any issues before the next release.
Regards |
No Format |
Hello Apache Geode Community,
It's time to update the 3rd-party libraries used by GEODE. We need a volunteer to take on this responsibility.
https://github.com/apache/geode/blob/develop/dev-tools/dependencies/README.md describes how to carry out this task.
It would be awesome to get this done within the next few weeks, to allow plenty of time to shake out any issues before the next release.
Regards,
{Release Manager} on behalf of the Apache Geode team |
Remove old unsupported branches (major/minor only)
Geode's N-2 support policy allows patch releases to be proposed only for its 3 most recent minors, so e.g. on the day 1.15.0 is released, 1.12 would become no longer supported. But this is not set in stone, so it's probably wise to start a discussion on the dev list before just running this command!
- remove 1.remove 1.<N-3> support branch, pipelines and RC tags:
Code Block | ||
---|---|---|
| ||
geode/dev-tools/release/end_of_support.sh -v 1.{N-3} |
...
end_of_support.sh -v 1.{N-3} |
Note tha end_of_support is a destructive command. It will prompt you to continue, then will delete the branch and pipeline. If run by accident, these can be restored by re-flying the pipeline and re-pushing the branch (if you or someone has an up-to-date local copy, otherwise google git reflog
for more ways to recover a deleted branch).
Send the announce mail
The template for this email was output at the end of promote_rc
, or you can re-generate it using geode/dev-tools/release/print_announce_email.sh
. Consider customizing the generated text if there are more upcoming releases (or even waiting and combining the announcements) or if there are notable fixes worth highlighting after the generic "contains a number of fixes".
*** Important: Send the email from your apache email ID*** (otherwise announce@apache.org will bounce. See https://infra.apache.org/committer-email.html for how to send email from your apache email address)
*** Important: Send the email as plain text***(otherwise announce@apache.org will reject the email. If using gmail, at the bottom of the compose window, click the three-dot menu then click Plain text mode)
Example:
To: user@geode.apache.org, announce@apache.org, dev@geode.apache.org
Subject: [ANNOUNCE] Apache Geode 1.13.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)Geode {version e.g. 1.13.0}
No Format |
---|
The Apache Geode community is pleased to announce the availability of Apache Geode {version e.g. 1.13.0}. 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 e.g. 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. For the full list of changes please review the release notes: https://cwiki.apache.org/confluence/display/GEODE/ Release+Notes#ReleaseNotes-{version e.g. 1.13.0} The release artifacts can be downloaded from the project website: httphttps://geode.apache.org/releases/ The release documentation is available at: httphttps://geode.apache.org/docs/guide/{version eg. in the format as 112 or 113 or 114}/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 |
...