...
- We expect that the majority of upgrades will be done via merging of automated Dependabot PRs.
- When reviewing a dependency update PR, note that increasing an upper bound may not be sufficient to exercise the new version in integration test suites. Committers can temporarily include a commit to a PR that increases the lower for a dependency, run integration tests, once they pass, remove the lower bound constraint. Sample PR that followed this process: https://github.com/apache/beam/pull/25786/commits. See an example of a PR review that followed this process, and identified a breaking change: https://github.com/apache/beam/pull/17615.
- Prefer to make risky dependency updates early in the release cycle, for example after a release cut, to have more time to test and identify issues before next release.
- When a newer version of a dependency is installed in job submission, and an older version of a dependency is installed in Beam container images, a misconfiguration can occur when Beam Job graph captures some of the dependency functions in serialized DoFn code: https://github.com/apache/beam/issues/33639 . To reflect the update in Beam containers, you may need to update dependency versions used in Beam container images. There is a workflow that updates the dependency versions once per release cycle, shortly after a release is cut. If you merge dependency upgrade PR after the script ran, you may need to run a gradle command or manually update the versions in requirements files. Such changes should be also done early in the release cycle.
When to update the versions?
...