Comment #5 on issue 210 by ken...@google.com: Java code should detect
incompatible runtime library version
Kenton, one of the reasons we've created the "shared" model artifact
pre-compiled is to avoid re-generation of src files and recompiling them
time we run a build, which is done my many multiple projects. Is it
have protoc be smart about the files it re-generates, and just like javac,
only "compile" the ones that have changed, not the ones that have already
been generated before?
I don't understand what this has to do with the bug. Can't you just update
your pre-compiled protos whenever you update your protobuf version?
But to answer your question: it's generally the responsibility of the
build system to detect when changes have occurred and avoid re-running
commands. If none of the input .protos have changed, and the protoc binary
has not changed, then the build system should recognize that there's no
reason to run it.
Also, since you've indicated that the versions of protobuf-java are not
intended to be backwards compatible to each other, would it be better to
the versioning scheme to be just sequential, instead of following the
major.minor.patch convention? This way the build systems like Maven and
would detect the incompatibility during build time and not allow
2.0.3 and 2.3.0 to be build-compatible.
No, our version numbering scheme should not be dependent on some build
However, if there is a way to communicate the incompatibility to Maven
without changing the public-facing version number, I'm happy to do that.
We do something like that in C++: we bump the SONAME with every release,
so protobuf 2.3.0 corresponds to libprotobuf.so.6, whereas 2.2.0 was
You received this message because you are subscribed to the Google Groups "Protocol
To post to this group, send email to proto...@googlegroups.com.
To unsubscribe from this group, send email to
For more options, visit this group at