Hi dev@, For some time we have had discussions around what Beam 3 could look like, and proposed features and milestones where we would decide to call the next release "Beam 3" - see https://s.apache.org/beam3-milestones. It was proposed that we move to Beam 3.0 after 2.74.0. But:
- Wearing my "Beam contributor" hat: I do not think we need a major version bump to accomplish the same goals. - Wearing my "Google lead" hat: my team is still building all the same things, but no longer pushing for this "Beam 3" version bump in the near future. The proposed changes can be categorized into breaking changes (where semver dictates a major version bump) and non-breaking (where we would do a major version bump just to mark a collection of major features or a new direction). - Breaking changes: some had been scheduled for minor releases, with others put on Beam 3.0 (see trackers [1] and [2] for details). We know now from experience that we can safely deliver valuable breaking changes with minor version releases. - Non-breaking changes: we have been delivering these, and can continue to deliver them with incremental releases. Most notably the key feature tracker at [4] Details of the breaking changes that would now be on a minor release: - End Java 8 Support: Java 8 support has been deprecated since Beam 2.66.0 [3]. Some core Beam dependencies have dropped Java 8 support (e.g., Avro 1.12, gcs-connector 3, Iceberg 1.7). This forces us to drop Java 8 support sooner than Beam 2.75. Certain dependencies have even dropped Java 11 support or plan to (e.g., Debezium 3, Neo4j 5, upcoming Iceberg 1.11). Moving forward, the list of supported Java versions can evolve across minor releases, similar to the current approach for the Python SDK. - End Unmaintained Runner Support: Support for runners tied to Java 8 (such as Samza) will end when Beam discontinues Java 8 support [1]. Other unmaintained runners are deferred unless they create a major maintenance burden. - Removal of Deprecated API and Default Behavior Changes: Listed in [1], these are currently deferred (e.g. the removal of duplicated coders). But, as with the other breaking changes, we can make this over minor versions if they are valuable enough. (and maybe use a flag to restore old behavior for a couple releases) Basically, we can do all the things we want to do without a major version change, and without coupling the fates of unrelated projects. In many ways, Beam's minor version has always been something "in between" the semver major and minor version concepts. And I just want to also be really clear that it is the Beam community (and, ultimately, the PMC) that makes decisions for Beam. I am just sending this as my opinion, and information about where my Google team will spend our attention and time. Kenn [1] Beam 3 Java SDK breaking changes: https://github.com/apache/beam/issues/35836 [2] Beam 3 Python SDK breaking changes: https://github.com/apache/beam/issues/36101 [3] [Task]: Deprecate Java8: https://github.com/apache/beam/issues/31678 [4] Beam 3 key features tracker: https://github.com/apache/beam/issues/36173
