Changing dependency to provided is a breaking change for sdks-java-core because all users of Beam would have to explicitly pass their Avro version once they upgrade their Beam version. That's not so nice but maybe is the intended behavior.
A softer approach would be to let it as it is (1.8) and document explicitly that we check upwards compatibility with 1.9 and suggest users to explicitly override the version if required. I have not followed your work on the compatibility tests but I am curious what is the issue with Avro 1.10? On Tue, Dec 1, 2020 at 5:23 PM Piotr Szuberski <[email protected]> wrote: > > I'd like to add tests verifying that Beam is compatible with both Avro 1.8 > and 1.9 similar to what has been done to Hadoop and Kafka. > > Probably all Avro dependencies would have to be changed from compile to > provided - won't it be problematic for users? They will be broken after the > update unless they add Avro dependency. On the other hand they'll be able to > choose which version do they prefer. > > At the moment Beam doesn't work with Avro 1.10 so users will be resticted to > use either 1.8 or 1.9. > > Does changing Avro dependencies to provided sounds reasonable? Are there > particular modules that should not be changed? Or is there a better approach?
