Page History

...

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 meat 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.

...

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

???

Maintenance of CI builds and infrastructure

...

• 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 branches
  • blink  - 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

...