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
