...
Expand | ||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||||||||||||||||||||
Before your first release, you should perform one-time configuration steps. This will set up your security keys for signing the release and access to various release repositories. To prepare for each release, you should audit the project status in the JIRA issue tracker, and do necessary bookkeeping. Finally, you should create a release branch from which individual release candidates will be built. One-time setup instructionsGPG KeyYou need to have a GPG key to sign the release artifacts. Please be aware of the ASF-wide release signing guidelines. If you don’t have a GPG key associated with your Apache account, please create one according to the guidelines. Determine your Apache GPG Key and Key ID, as follows:
This will list your GPG keys. One of these should reflect your Apache account, for example:
Here, the key ID is the 8-digit hex string in the Now, add your Apache GPG key to the Flink’s Configure
You may drop the You may wish to start
Access to Apache Nexus repositoryConfigure access to the Apache Nexus repository, which enables final deployment of releases to the Maven Central Repository.
Website development setupGet ready for updating the Flink website by following the website development instructions. Create a new version in JIRAWhen contributors resolve an issue in JIRA, they are tagging it with a release that will contain their changes. With the release currently underway, new issues should be resolved against a subsequent future release. Therefore, you should create a release item for this subsequent release, as follows:
(Note: Only PMC members have access to the project administration. If you do not have access, ask on the mailing list for assistance.) Triage release-blocking issues in JIRAThere could be outstanding release-blocking issues, which should be triaged before proceeding to build a release candidate. We track them by assigning a specific The list of release-blocking issues is available at the version status page. Triage each unresolved issue with one of the following resolutions:
Review and update documentationThere are a few pages in the documentation that need to be reviewed and updated for each release.
Cross team testingFor user facing features that go into the release we'd like to ensure they can actually be used by Flink users. To achieve this the release managers ensure that an issue for cross team testing is created in the Apache Flink Jira. This can and should be picked up by other community members to verify the functionality and usability of the feature.
Unless the pages have not been updated before, please create a JIRA ticket and mark it as release blocker.Setup environment variablesSet up a few environment variables to simplify commands that follow. (We use
Review Release Notes in JIRAJIRA automatically generates Release Notes based on the Open the release notes from the version status page by choosing the release underway and clicking Release Notes. You should verify that the issues listed automatically by JIRA are appropriate to appear in the Release Notes. Specifically, issues should:
Adjust any of the above properties to the improve clarity and presentation of the Release Notes. Ensure that the JIRA release notes are also included in the release notes of the documentation (see section "Review and update documentation"). Content of Release Notes field from JIRA ticketsTo get the list of "release notes" field from JIRA, you can ran the following script using JIRA REST API:
fixVersion%20%3D%201.11.0 defines tickets for which fix version will be searched for (in this case it is 1.11.0) .
Verify that a Release Build WorksRun Create a release branchRelease candidates are built from a release branch. As a final step in preparation for the release, you should create the release branch, push it to the code repository (you should probably do this once the whole process is done), and update version information on the original branch. Set up a few environment variables to simplify Maven commands that follow. (We use Code Block | | |||||||||||||||||||||||||||||||||||
|
Expand | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||
Major releaseIf you are doing a new major release, you need to update Flink version in two repositories Flink repositoryCreate a branch for the new version that we want to release before updating the master branch to the next development version:
The newly created branch needs to be pushed to the official repository. Afterwards fork off from After pushing the new major release branch, as the last step you should also update the documentation build bot to also build the documentation for the new release branch. Check Managing Documentation on details on how to do that. You may also want to manually trigger a build to make the changes visible as soon as possible. Flink Benchmarks repositoryInside https://github.com/apache/flink-benchmarks repository you need to manually update the
|
Expand | |||||
---|---|---|---|---|---|
| |||||
Minor releaseIf you're creating a new minor release you do not need to modify Flink Benchmarks. You will skip the "Major release" step and simply check out the the already existing branch for that version:
|
The rest of this guide assumes that commands are run in the root (or tools directory) of a repository on the branch of the release version with the above environment variables set.
Checklist to proceed to the next step
- 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.flink
listed underStaging Profiles
in Nexus - Release Manager’s Nexus User Token is configured in
settings.xml
- JIRA release item for the subsequent release has been created
- There are no release blocking JIRA issues
- Release Notes in JIRA have been audited and adjusted
- Update upgrade compatibility table (
docs/ops/upgrading.md).
- (major only) Release branch has been created and pushed if it is a major release.
- (major only) Originating branch has the version information updated to the new version(major/minor only) Jenkins deployment updated to create snapshot artifacts for release branch (see here)
- (major /minor only) Cron end-to-end-tests branch setup for release branch(major only) Make sure flink-docker has dev-x.y branch and docker e2e tests run against this branch
- (major /minor only) Update upgrade compatibility table ( docs/ops/upgrading.md.docs/config.toml has toml has been updated appropriately.
- (major only) The new documentation for the new major releases release is visible under under https://cinightlies.apache.org/projects/flink/flink-docs-release-$SHORT_RELEASE_VERSION (after at least one doc build finishes).
- (major only) The new documentation for the new major releases do release does not contain "-SNAPSHOT" in its version title, and all links refer to the corresponding version docs instead of master.
...