On 16/06/2015 10:54, Steve Loughran wrote:
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.
I completely get your point, however we are faced with t
On Jun 16, 2015, at 2:54 AM, Steve Loughran wrote:
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.
Not in branch-2, but cert
> On 15 Jun 2015, at 22:31, Colin P. McCabe wrote:
>
> On Mon, Jun 15, 2015 at 7:24 AM, Allen Wittenauer wrote:
>>
>> On Jun 12, 2015, at 1:03 PM, Alan Burlison wrote:
>>
>>> On 14/05/2015 18:41, Chris Nauroth wrote:
>>>
As a reminder though, the community probably would want to see a
On Mon, Jun 15, 2015 at 7:24 AM, Allen Wittenauer wrote:
>
> On Jun 12, 2015, at 1:03 PM, Alan Burlison 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 pe
On Mon, Jun 15, 2015 at 8:57 AM, Andrew Purtell wrote:
> I can't answer the original question but can point out the protostuff (
> https://github.com/protostuff/protostuff) folks have been responsive and
> friendly in the past when we (HBase) were curious about swapping in their
> stuff. Two signi
I can't answer the original question but can point out the protostuff (
https://github.com/protostuff/protostuff) folks have been responsive and
friendly in the past when we (HBase) were curious about swapping in their
stuff. Two significant benefits of protostuff, IMHO, is ASL 2 licensing and
ever
Anyone have a read on how the protobuf folks would feel about that? Apache
has a history of not accepting projects that are non-amicable forks.
On Mon, Jun 15, 2015 at 9:24 AM, Allen Wittenauer wrote:
>
> On Jun 12, 2015, at 1:03 PM, Alan Burlison
> wrote:
>
> > On 14/05/2015 18:41, Chris Nauro
On Jun 12, 2015, at 1:03 PM, Alan Burlison 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 sign
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 note
> On 19 May 2015, at 17:59, Colin P. McCabe wrote:
>
> I agree that the protobuf 2.4.1 -> 2.5.0 transition could have been
> handled a lot better by Google. Specifically, since it was an
> API-breaking upgrade, it should have been a major version bump for the
> Java library version. I also fee
I pushed it out to a github fork:
https://github.com/sjlee/protobuf/tree/2.5.0-incompatibility
We haven't observed other compatibility issues than these.
On Tue, May 19, 2015 at 10:05 PM, Chris Nauroth
wrote:
> Thanks, Sangjin. I'd be interested in taking a peek at a personal GitHub
> repo or
Thanks, Sangjin. I'd be interested in taking a peek at a personal GitHub
repo or even just a patch file of those changes. If there were
incompatibilities, then that doesn't bode well for an upgrade to 2.6.
--Chris Nauroth
On 5/19/15, 8:40 PM, "Sangjin Lee" wrote:
>When we moved to Hadoop 2
When we moved to Hadoop 2.4, the associated protobuf upgrade (2.4.1 ->
2.5.0) proved to be one of the bigger problems. In our case, most of our
users were using protobuf 2.4.x or earlier.
We identified a couple of places where the backward compatibility was
broken, and patched for those issues. We
I agree that the protobuf 2.4.1 -> 2.5.0 transition could have been
handled a lot better by Google. Specifically, since it was an
API-breaking upgrade, it should have been a major version bump for the
Java library version. I also feel that removing the download links
for the old versions of the n
On 15/05/2015 09:44, Steve Loughran wrote:
Now: why do you want to use a later version of protobuf.jar? Is it
because "it is there"? Or is there a tangible need?
No, it's because I'm looking at this from a platform perspective: We
have other consumers of ProtoBuf beside Hadoop and we'd obviou
On 14 May 2015, at 15:23, Alan Burlison
mailto:alan.burli...@oracle.com>> wrote:
I think bundling or forking is the only practical option. I was looking to see
if we could provide ProtocolBuffers as an installable option on our platform,
if it's a version-compatibility nightmare as you say, th
Thanks for that link, Alan. That looks like a useful site!
Ideally, the Protocol Buffers project would give a clear statement about
wire compatibility between 2.5.0 and 2.6.1. Unfortunately, I can't find
that anywhere. If it's not documented, then it's probably worth following
up on the Protoco
On 13/05/2015 17:13, Chris Nauroth wrote:
It was important to complete this upgrade before Hadoop 2.x came out of
beta. After that, we committed to a policy of backwards-compatibility
within the 2.x release line. I can't find a statement about whether or
not Protocol Buffers 2.6.1 is backwards
Some additional details...
A few years ago, we moved from Protocol Buffers 2.4.1 to 2.5.0. There
were some challenges with that upgrade, because 2.5.0 was not
backwards-compatible with 2.4.1. We needed to coordinate carefully with
projects downstream of Hadoop that receive our protobuf classes t
On May 13, 2015, at 5:02 AM, Alan Burlison wrote:
> The current version of Protocol Buffers is 2.6.1 but the current version
> required by Hadoop is 2.5.0. Is there any reason for this, or should I log a
> JIRA to get it updated?
The story of protocol buffers is part of a shameful pas
The current version of Protocol Buffers is 2.6.1 but the current version
required by Hadoop is 2.5.0. Is there any reason for this, or should I
log a JIRA to get it updated?
--
Alan Burlison
--
21 matches
Mail list logo
