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. > > > 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 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. cheers, Colin
