On Sep 10, 7:10 pm, Jason Hsueh <jas...@google.com> wrote:
> Can you provide a small reproduction of the problem? A couple common errors:
> - custom options need to be specified as "option (<option_name>) = <value>;"
> (parentheses around the identifier)
> - if you're using the option in a different package than the one in which
> its defined, it needs to be qualified with the package name

Yes, I'm pretty sure I followed the instructions in the documentation.

> Also, note that protocol buffers were originally designed to get away from
> having to deal with version numbers (see "A bit of 
> history":http://code.google.com/apis/protocolbuffers/docs/overview.html) 
> Typically,
> you would define your protocol in such a way that different versions are
> still compatible. When that's not practical/possible, people may just switch
> to entirely new messages.

We have a Java-program A which spawns a C++-program B, and A needs to
know that B can deal with the messages it sends, and if new
functionality in the protocol is added, A needs to be able to figure
out if B is sufficiently new to handle the new functionality. So this
is strictly not so much a protocol version, but rather a program

I solved this by having one version number encoded in the C++-program
and another in the Java-program, and a version-message is exchanged
when they hook up. If B does not present a new enough version number,
the program is terminated. The only drawback is that I have to change
the version number in two places when adding functionality to the

You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
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 

Reply via email to