THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
- Be appropriately classified as Bug, New Feature, Improvement, etc.
- Represent noteworthy user-facing changes, such as new functionality, backward-incompatible API changes, or performance improvements.
- Have occurred since the previous release; an issue that was introduced and fixed between releases should not appear in the Release Notes.
- Have an issue title that makes sense when read on its own.
// Needs to be fixed.
// I found this section in flink release guide. Not sure why our incubating release guide didn't have it.
--------------------------------------------------------------------------------------------------------
Review and update documentation
There are a few pages in the documentation that need to be reviewed and updated for each release.
- Ensure that there exists a release notes page for each non-bugfix release (e.g., 1.5.0) in
./docs/release-notes/, that it is up-to-date, and linked from the start page of the documentation. - Upgrading Applications and Flink Versions: https://ci.apache.org/projects/flink/flink-docs-master/ops/upgrading.html
- please extend this list.
Unless the pages have not been updated before, please create a JIRA ticket and mark it as release blocker.
--------------------------------------------------------------------------------------------------------
Verify that a Release Build Works
...
- Release Manager’s GPG key is published to dist.apache.org
- Release Manager’s GPG key is configured in git configuration
- Release Manager has org.apache.hudi listed under Staging Profiles in Nexus
- Release Manager’s Nexus User Token is configured in settings.xml
- JIRA release item for the subsequent release has been created
- All test failures from branch verification have associated JIRA issues
- There are no release blocking JIRA issues
- Release branch has been created
- Release Notes have been audited and added to RELEASE_NOTES.md// Add an entry to documentation ?
Build a release candidate
...
- Follow the instructions for cutting a doc for this new release.
- Build the site locally and ensure the new doc version is available as intended.
- Update site using instructions
...
Promote the release
Once the release has been finalized, the last step of the process is to promote the release within the project and beyond. Please wait for 24h after finalizing the release in accordance with the ASF release policy.
...