Comment #12 on issue 210 by aantono: Java code should detect incompatible runtime library version

Sorry for not replying to this sooner, things have been a bit hacktik. The basic answer is Yes, Maven, as well as Ivy will resolve the artifact's version based on the jar's naming convention - name-major.minor.patch-extra.extention. So if a jar is named protobuf-java-2.3.0.jar, according to default conventions it is expected to be compatible with protobuf-java-2.2.0.jar, etc. If, however, the names are protobuf-java-2.jar and protobuf-java-3.jar, they would not be viewed as compatible by default (one would have to explicitly indicate the compatibility rules as being major-line compatible). In case of protocol buffers, I see a number of artifacts produced by the project, there is a version of protobuf format, which defines what is available as far as syntax and options that can go into the .proto files (meaning a protoc compiler of version 2.3 should be able to compile proto files that were intended for protoc 2.2, etc), and there are also language-specific libraries that enable various languages (java, c++, python, etc) to be capable of consuming the binary payload and represent it in the forms of objects within those languages. To me, those appear as separate artifacts that have a separate versioning scheme and an indication of being able to handle a protobuf byte stream as defined by a given version of protobuf encoding specification. So just like you separately version the .so libs for cpp, the same applies to the java versioning scheme and other languages as well (meaning no need to match the java's protobuf jar to the version of protoc and .proto syntax spec)

You received this message because you are subscribed to the Google Groups "Protocol 
Buffers" group.
To post to this group, send email to
To unsubscribe from this group, send email to
For more options, visit this group at

Reply via email to