Thanks, Ben. I understand the "be liberal in what you accept" philosophy that allows mismatched versions of a Thrift client and server to talk (regardless of whether that's a good idea <https://techblog.workiva.com/tech-blog/postel%E2%80%99s-cycle>). It seems that you're suggesting, therefore, that pinning specific versions of external Thrift dependencies is unnecessary because due to interoperability.
However, I don't see that this solves the problem of generating code from Thrift files that have external includes (unless I keep a copy of them locally like you suggest). I was hoping for a solution that lets each service be the source of truth for the single copy of its own Thrift definition instead of keeping copies within dependent services. On Mon, Nov 9, 2015 at 10:49 AM, BCG <[email protected]> wrote: > On 11/9/2015 at 11:32 AM, "Tom Deering" <[email protected]> wrote: > > > >Does Thrift have a solution for generating code with distributed, > >versioned > >dependencies (includes)? For example, suppose we have 3 > >repositories with > >Thrift definitions: > > > >*Foo:* Defines types, FooService. > >*Bar (includes Foo):* Defines types, BarService extends FooService. > >*Baz (includes Bar, Foo):* Defines BazService extends FooService, > >uses > >types in Foo, Bar. > > > >Suppose we want to generate code for Baz, which was written when > >Foo and > >Bar were at commits X and Y. Is there a standard way to express > >pinned > >Thrift dependencies and generate code with the necessary artifacts > >at the > >necessary versions? This is a solved problem for most programming > >languages, but how about Thrift IDL? > > > > If you read section 5 of the Thrift whitepaper ( > https://thrift.apache.org/static/files/thrift-20070401.pdf), Thrift's > versioning solution is outlined there. Generated code handles data > definition changes robustly... there is a case analysis in there though > that can alert you to the pitfalls. > > In summary your best bet is probably to implement default behavior for new > fields when you update your servers. Don't remove fields if you can avoid > it because new clients won't send the field when interacting with old > servers that might not have a default behavior defined. > > To me, playing nice with Thrift's versioning solution is better than > pinning to a specific version of an interface... if you need to do that > though, you could simply change the namespace of your IDL to force clients > to recompile. The other thing that comes to mind is to create a repository > for the IDL dependencies you need in your version control system, and > create a tag for the specific combination of versions that you need. > Truthfully though, if you follow the strategy in the Thrift whitepaper, > neither of these measures should be necessary. > > HTH > > Ben > > -- Tom Deering, PhD | (563) 249-9277 | Software Engineer, Workiva
