Comment #5 on issue 210 by Java code should detect incompatible runtime library version

Kenton, one of the reasons we've created the "shared" model artifact that is pre-compiled is to avoid re-generation of src files and recompiling them every time we run a build, which is done my many multiple projects. Is it possible to
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 really intended to be backwards compatible to each other, would it be better to change
the versioning scheme to be just sequential, instead of following the
major.minor.patch convention? This way the build systems like Maven and Ivy would detect the incompatibility during build time and not allow something like
2.0.3 and 2.3.0 to be build-compatible.

No, our version numbering scheme should not be dependent on some build system's conventions.

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, whereas 2.2.0 was, etc.

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