Info |
---|
This page is work in progress! |
Flink Release Management consists of the following tasks:
- Managing the feature development for the release
- Maintenance of CI builds and infrastructure (for
master
and the two most-recently release Flink versions) - Jira maintenance
These tasks are not necessarily exclusively done by the release manager. The community should take care of it. The release management pages are used to plan releases and collect features that should be in the release, major blockers, and breaking changes introduced by the release.
- 1.13 Release
- 1.12 Release
- 1.4 Release
- 1.1 Release
- 1.0 Release
responsibility of the release manager is to make sure that a certain quality and stability of the relevant code base is achieved.
Additionally, any release-related documentation should be kept up-to-date (e.g. Release Management and Feature Plan or Creating a Flink Release)
Organization
Preparing a Release Cycle
- Setting up a release page (see 1.17 Release as a template)
- Announcing the plan for the release cycle (e.g. feature freeze date)
Regular Sync
It's a good habit to meet on a regular basis to sync on the developments of the current release cycle. A summary should be kept in the release's wiki article (see Release Management and Feature Plan) and sent to the dev mailing list to keep the community up-to-date.
Feature Freeze
The feature freeze is a set date until which features can be added to master
. After the feature freeze, no additional feature are allowed to be merged into master
. Only bugfixes and documentation changes are allowed. The goal is to stabilize master
before cutting of the release branch. The feature freeze date is communicated at the beginning of a release cycle. It's not uncommon that the date will be changed during the release cycle if there are valid reasons to do so. Such a decision needs to be discussed in the dev mailing list (see 1.17 feature freeze extension discussion).
The time between announcing the feature freeze and cutting the release branch should be as short as possible since it's blocking work that should go into future releases.
Release Testing
Release testing happens after the release branch is cut and CI is stable enough. The goal is to test features manually that ended up in this build. Additionally, the documentation for these feature should be available. Any blocking issues that come up during the release testing need to be addressed before going forward with the release.
Release Metrics
- Count contributors, the following git commands can be used to count contributors for given commit range of current branch:
git shortlog --summary startCommitId..endCommitId | awk -F ' ' '{$1=""; print $0 }'|sort -n|awk 'BEGIN{ORS=", "}{print $0}'
- Count resolved issues, the JIRA filter can be used to count the resolved issues in this version:
project = flink AND status in (closed, resolved, Fixed, Completed, Done) AND fixVersion in (1.17.0)
Maintenance of CI builds and infrastructure
The release manager should ensure stability of master
and the two most-recently published Flink versions in terms of CI. Builds can be monitored on AzureCI Flink build overview (see Testing Infrastructure for further details on the build process). Failed builds are reported to Apache Flink's #builds Slack channel.
Other tasks:
- Monitoring the remote branches. Sometimes, there are remote branches created accidentally in the Apache Flink repo. Branches should generally been created in the forks. We might want to reach out to contributors to delete these accidentally created remote branches. The following branches shouldn't be touched:
master
&release-*
- Flink versioning branchesblink
- Branch holding the legacy blink code. This one is kept for historical purposes.experiment_gha_docs
&exp_github_actions
- These branches are kept as part of the Github Actions migration efforts (see Chesnay Schepler's comment in the related ML post).dependabot/*
- These branches are temporarily created by dependabot for version bumps (related ML announcement).
Performance Regression Tests
Performance regression tests are used to monitor that there are no changes that reduce the performance of Flink. There is more documentation on this topic in Codespeed / Benchmarks. Regressions are reported in Apache Flink's #flink-dev-benchmarks Slack channel.
Jira maintenance
- Build failures should be reported in the corresponding Jira issue (or a Jira issue should be created if none exists, yet). Contributors should be pinged to fix instabilities as soon as possible to ensure a stable infrastructure of the course of the release cycle. More details on Jira issues can be found on the Flink Jira Process wiki page.
- Newly created Jira issue should follow the Flink Jira Process guide
- Jira issues should be correctly labeled with fixVersion, affectedVersion, component
Hints around AzureCI/Jira usage
- AzureCI's console log output view supports line bookmarks: Each line number on the left side of the console log view has its own link assigned to it
- There are several URLs with placeholder that might be handy when accessing Jira through your browser using Firefox's bookmark keywords or Chrome's search engine feature:
https://issues.apache.org/jira/browse/FLINK-%s
enables a lookup by ID (i.e. "<keyword> 123
" in the browser's address field opens
straight away)Jira server ASF JIRA serverId 5aa69414-a9e9-3523-82ec-879b028fb15b key FLINK-123 https://issues.apache.org/jira/browse/FLINK-1?filter=-1&jql=project%20%3D%20FLINK%20AND%20text%20~%20%22%s%22%20ORDER%20BY%20id%20DESC
search for any FLINK issue based on a query string (i.e. "<keyword> asd
" in the browser's address field opens a search result containing all Flink Jira issues having the search term "asd" in it; handy for looking up Jira issues related to some test instability)https://issues.apache.org/jira/browse/FLINK-10106?filter=-1&jql=project%20%3D%20FLINK%20AND%20text%20~%20%22%s%22%20AND%20status%20NOT%20IN%20(Closed%2C%20Resolved)
same as the query above but only for open FLINK Jira issues.
...