On 5 Jan 2017, at 6:34 PM, Martín Ferrari <tin...@tincho.org> wrote: > > Tim, > > On 04/01/17 02:28, Potter, Tim wrote: >> I was poking at this last year before Christmas and grpc is actually up to >> SupportPackageIsVersion4 now. )-: > > Yes. This was indeed the issue. Packages including pre-generated > protobuf go filess, were using the older symbols. So these packages were > not building any more. > >> Should be make it a general policy to regenerate proto files for each new >> grpc release? This sounded good to me until I discovered that etcd3 has >> the grpc as an official API,. I think that I saw the etcd.proto file >> (for etcd2) >> in the source of another package (swarmkit?). Not sure whether the version >> business is going to mess is up here as well - are the wire formats >> incompatible >> between the different versions? > > I don't think the wire formats are incompatible, but I haven't checked.
I believe that backwards compatibility is possible at both the protobuf and grpc levels by design but requires some knowledge and forethought by the developer. It may Just Work but yeah more research is required. I found this article about Python protobuf version issues which might map across to golang: http://wtanaka.com/node/8203 > In my opinion, no package should be shipping .pg.go files from upstream. > Instead, we should re-generate those at build time, using the current > versions of protobuf-compiler and grpc. So, next time there is an > incompatible change, we only need to rebuild the libraries that generate > .pb.go files. I remember regenerating .pb.go files for one package but not at build time so it's probably broken again now. Build-time sounds like the most Debian-ish way to do things. >> I think I decided that vendoring the source for grpc in each package where >> it's >> needed was going to be easier. The Debian way of having a single source >> for a library is not really working here. > > I honestly don't like that. I understand we vendor sometimes when there > is no other option, or the extra work is too much. But in this case, we > only need to fix the package once. > > In the future, we should also start versioning grpc and > protobuf-compiler, so we can detect this automatically. Hmm - also a good idea. A problem would be that I don't think that bug and security patches are not backported to old release, but that's no worse than what we have at the moment. So your proposal is to do both of regenerate .pb.go files at build time and version the grpc package with the SupportPackageIsVersionX number? Sounds good to me but a lot of work. (-: Tim. > > > -- > Martín Ferrari (Tincho)
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Pkg-go-maintainers mailing list Pkgemail@example.com http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers