I would say it depends on what languages you're using and how your build system is set up. For any language other than C++, you have the option of just committing the protobuf generated code into source control and then you can handle it the same way you would handle any other code dependency. We make an effort to ensure that older generated code is compatible with newer library versions so that this use case works (not for C++, though). This can be a good option because it keeps the build process simple and you don't have to deal with protoc except when you update a .proto file. And you don't have to make everyone on your team download or build a protoc binary just to build the project.
On the other hand you might still need to run protoc as part of your build if you're using C++ or if you don't want to commit generated artifacts into your repo. For C++ it's not a great idea to commit the generated code because it will generally break when you upgrade to a newer version of the protobuf library. In that case I'm not sure if there's a best practice but you are right that protobuf is good at handling out-of-date schemas and so keeping separate copies of .proto files is a reasonable option. If you do this I would just recommend having one repository be the official "owner" of the .proto file and only make new modifications there, copying those changes to the other repos periodically. The reason is that if separate copies diverged by making competing changes to their copies of the .proto file, they could end up reusing the same tag number with incompatible types. On Wed, Oct 26, 2016 at 10:46 AM, <buchanae.o...@gmail.com> wrote: > I have a simple server/clients setup with protobufs. The server API code > lives in one VCS repository, and multiple clients live in multiple other > repositories. Are there any best practices or common patterns for how to > store the .proto files related these interfaces? > > It seems like the best option would be to have each repository store its > own .proto file, thereby documenting the interface it supports. Seems like > one of the major features of protobufs is allowing clients to have an out > of date schema, and this approach seems to fall in line with that. > > Thoughts? > > Thanks! > > -- > You received this message because you are subscribed to the Google Groups > "Protocol Buffers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to protobuf+unsubscr...@googlegroups.com. > To post to this group, send email to protobuf@googlegroups.com. > Visit this group at https://groups.google.com/group/protobuf. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Protocol Buffers" group. To unsubscribe from this group and stop receiving emails from it, send an email to protobuf+unsubscr...@googlegroups.com. To post to this group, send email to protobuf@googlegroups.com. Visit this group at https://groups.google.com/group/protobuf. For more options, visit https://groups.google.com/d/optout.
