Is there any reason you couldn't shade your own protobuf dependency (using,
say, the Maven shade plugin
http://maven.apache.org/plugins/maven-shade-plugin/) to allow it to
interoperate with a dependency's older version?
On Tue, Jun 17, 2014 at 1:49 PM, Sangjin Lee sjl...@gmail.com wrote:
One
One case where generated APIs are not backward
compatible: https://code.google.com/p/protobuf/issues/detail?id=493
On Wednesday, April 16, 2014 7:22:41 PM UTC-7, Ilia Mirkin wrote:
On Wed, Apr 16, 2014 at 10:11 PM, Patrick Wendell pwen...@gmail.com
javascript: wrote:
Established based on
Hi All,
I work on Apache Spark which is an open source project. We have recently
been dealing with a lot of pain due to the fact that the Java Protobuf
libraries for 2.4.X and 2.5.0 are not binary compatible. This makes it
really difficult for users to include two dependencies A and B that
While I don't speak for Google, I believe it's fairly well-established
that 2.4 and 2.5 are considered to be major releases. Switching
between them requires regenerating the java files with protoc, as the
internal APIs used by the generated code tend to change. I believe
that in general the public
Established based on what conventions? I'm going based on the semantic
versioning guidelines here:
http://semver.org/
Basically what I'd like to understand is whether Google cares about this or
not, because changing public API's is a big problem for downstream
projects. It means that if you want
On Wed, Apr 16, 2014 at 10:11 PM, Patrick Wendell pwend...@gmail.com wrote:
Established based on what conventions?
On the convention of how protobuf releases have been done... Would you
be happier if it was protobuf2 4.0 and protobuf2 5.0?
It means that if you want to write a library that uses
