Details
-
Sub-task
-
Status: Resolved
-
Major
-
Resolution: Done
-
1.20.0
-
None
Description
If you are doing a new major release, you need to update Flink version in the following repositories and the AzureCI project configuration:
Patch releases don't require the these repositories to be touched. Simply checkout the already existing branch for that version:
$ git checkout release-$SHORT_RELEASE_VERSION
Flink repository
Create a branch for the new version that we want to release before updating the master branch to the next development version:
$ cd ./tools tools $ releasing/create_snapshot_branch.sh tools $ git checkout master tools $ OLD_VERSION=$CURRENT_SNAPSHOT_VERSION NEW_VERSION=$NEXT_SNAPSHOT_VERSION releasing/update_branch_version.sh
In the master branch, add a new value (e.g. v1_16("1.16")) to apache-flink:flink-annotations/src/main/java/org/apache/flink/FlinkVersion as the last entry:
// ... v1_12("1.12"), v1_13("1.13"), v1_14("1.14"), v1_15("1.15"), v1_16("1.16");
Additionally in master, update the branch list of the GitHub Actions nightly workflow (see apache/flink:.github/workflows/nightly-trigger.yml#L31ff): The two most-recent releases and master should be covered.
The newly created branch and updated master branch need to be pushed to the official repository.
Flink Docker Repository
Afterwards fork off from dev-master a dev-x.y branch in the apache/flink-docker repository. Make sure that apache/flink-docker:.github/workflows/ci.yml points to the correct snapshot version; for dev-x.y it should point to x.y-SNAPSHOT, while for dev-master it should point to the most recent snapshot version ({[$NEXT_SNAPSHOT_VERSION}}).
After pushing the new minor release branch, as the last step you should also update the documentation workflow 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 Benchmark Repository
First of all, checkout the master branch to dev-x.y branch in apache/flink-benchmarks, so that we can have a branch named dev-x.y which could be built on top of ($CURRENT_SNAPSHOT_VERSION).
Then, inside the repository you need to manually update the flink.version property inside the parent pom.xml file. It should be pointing to the most recent snapshot version ($NEXT_SNAPSHOT_VERSION). For example:
<flink.version>1.18-SNAPSHOT</flink.version>
AzureCI Project Configuration
The new release branch needs to be configured within AzureCI to make azure aware of the new release branch. This matter can only be handled by Ververica employees since they are owning the AzureCI setup.
Expectations (Minor Version only if not stated otherwise)
- Release branch has been created and pushed
- Changes on the new release branch are picked up by Azure CI
- master branch has the version information updated to the new version (check pom.xml files and
- apache-flink:flink-annotations/src/main/java/org/apache/flink/FlinkVersion enum)
- apache/flink:.github/workflows/nightly-trigger.yml#L31ff should have the new release branch included
- New version is added to the apache-flink:flink-annotations/src/main/java/org/apache/flink/FlinkVersion enum.
- Make sure flink-docker has dev-x.y branch and docker e2e tests run against this branch in the corresponding Apache Flink release branch (see apache/flink:flink-end-to-end-tests/test-scripts/common_docker.sh:51)
- apache-flink:docs/config.toml has been updated appropriately in the new Apache Flink release branch.
- The flink.version property (see apache/flink-benchmarks:pom.xml of Flink Benchmark repo has been updated to the latest snapshot version.