Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

It's a good habit to meat 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

???

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 threadannouncement).

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

...