> On 15 Jun 2015, at 22:31, Colin P. McCabe <cmcc...@apache.org> wrote: > > On Mon, Jun 15, 2015 at 7:24 AM, Allen Wittenauer <a...@altiscale.com> wrote: >> >> On Jun 12, 2015, at 1:03 PM, Alan Burlison <alan.burli...@oracle.com> wrote: >> >>> On 14/05/2015 18:41, Chris Nauroth wrote: >>> >>>> As a reminder though, the community probably would want to see a strong >>>> justification for the upgrade in terms of features or performance or >>>> something else. Right now, I'm not seeing a significant benefit for us >>>> based on my reading of their release notes. I think it's worthwhile to >>>> figure this out first. Otherwise, there is a risk that any testing work >>>> turns out to be a wasted effort. >>> >>> One reason at least: PB 2.5.0 has no support for Solaris SPARC. 2.6.1 does.
to be ruthless, that's not enough reason to upgrade branch-2, due to the transitive pain it makes all the way down. >> >> >> That's a pretty good reason. >> >> Some of us had a discussion at Summit about effectively forking >> protobuf and making it an Apache TLP. This would give us a chance to get >> out from under Google's blind spot, guarantee better compatibility across >> the ecosystem, etc, etc. >> >> It is sounding more and more like that's really what needs to happen. > > I agree that it would be nice if the protobuf project avoided making > backwards-incompatible API changes within a minor release. But in > practice, we have had the same issues with Jackson, Guava, jets3t, and > other dependencies. Nearly every important Hadoop dependency has made > backwards-incompatible API changes within a minor release of the > dependency... and that's one reason we are using such old versions of > everything. I don't think PB deserves to be singled out as much as it > has been. I think it does deserve as it was such an all-or-nothing change. Guava, well, we may keep it at 11.0, but we've made sure there are no classes used which aren't in the latest versions. Even where we depend on artifacts which need later versions (curator-2.7.1) we've addressed the version problem by verifying that you can actually rebuild curator with guava<-11.0 with everything working (curator-x-discovery doesn't compile, but we don't use that). So we know that unless a bit of curator uses reflection, we can run it against 11.x. And if someone wants to use a later version of Guava + hadoop-common, they can swap it in and hadoop will still work. Which is important as on Java 8u45 + you do need a recent Guava. In contrast, protobuf needed a co-ordinate update across everything, every project which had checked in their generated protobuf files had to rebuild and check in, which guarantees they could no longer work with protobuf 2.4 Jackson? its broken-ness wasn't so obvious: if we'd known I wouldn't have let it go updated. It's now on the risk list and I don't see us updating that for a long time. > I think the work going on now to implement CLASSPATH > isolation in Hadoop will really be beneficial here because we will be > able to upgrade without worrying about these problems. +1
