Minor note that Gradle 5 added support for BOMs[1]. I think attempting to perform the upgrade (whether to use BOM or not) will be a concerted effort every time to minimize the amount of breakage to users while maximizing compatibility with the OSS ecosystem. Unfortunately I'm not aware of any dependency analysis tooling that can perform some validation stating that something is safe or not. If such a tool existed, it would make it much easier for projects to perform upgrades and would also help users as well.
1: https://dzone.com/articles/gradle-goodness-use-bill-of-materials-bom-as-depen On Wed, Nov 20, 2019 at 4:05 AM Elliotte Rusty Harold <elh...@ibiblio.org> wrote: > BOM or no BOM is an implementation detail. Using > com.google.clou:libraries-bom would make dependency management simpler > for developers, but the real issue is whether Beam can continue to > work with very old versions of the many libraries it depends on. Even > if this is acceptable for Beam, it's unlikely to be feasible for > anyone who needs to mix Beam code with other code. > > There should be no self-incompatibility between Google minor version > releases. All the Google libraries in question follow semantic > versioning. E.g. Pubsub 1.43 would be fully API compatible with Pubsub > 1.28, though not the reverse. However there are likely to be important > bug fixes in 1.43 and definitely new features that 1.28 would not > have. If there are any edge cases where this is not true, that's a bug > and if you file it against the repo we'll try to fix it. We're also > installing tooling to make this less likely to happen by accident. > However, right now any such problem is rare. > > Behavior differences are another story. It is entirely possible that > something like Pubsub 1.28 would simply no longer function due to > changes at the backend. There's a deprecation cycle, announcements, > and transition periods in all such cases; but a project like Beam > can't stay on old versions forever. If they try, the backends will > shift out from under them. > > Looking at Beam's dependencies, the only case where there are major > version changes to address is Guava. > This will take some work, but not an excessive amount. We should be > able to move this up to 28.1-android with few code changes and no > further API breaking changes in that library are planned for the > future. > > The remaining issues are pre-1.0 libraries. OpenCensus is a particular > thorn in my side. Ideally these should not be used, at all. However if > we must, we should not expose them on the Beam API surface and we need > to move them forward quickly as they change. > > -- > Elliotte Rusty Harold > elh...@ibiblio.org >
