golang-goprotobuf is special so let's start a new thread.
good call!
[...]
Now the question for Debian to move forward.
1. Should we bump golang-goprotobuf to v1.4+, this will break packages
that still uses golang-gogoprotobuf, and unlikely will be fixed.
2. Should we stick golang-goprotobuf at v1.3, and only go with
golang-google-protobuf package?
This means we need to help upstream to finish the transition to
protobuf v2 with golang-google-protobuf only.
It seems that we currently have 243 packages declaring a "Build-Depends" relationship in unstable on the old 1.3 golang-gogoprotobuf package, and "only" 7 on the new golang-google-protobuf-dev. That's an awful lot of breakage.
Shengjing, would it be feasible to keep golang-gogoprotobuf at 1.3 and have packages move over to google-protobuf-dev "peu-a-peu"? In principle, I think option 1 would be preferable if the goal is to move to protobuf v2 as fast as possible. Given the vast amount of packages that need porting, I'm not sure that we'd have the necessary engineering capacity for getting this done in a timely manner. If version 2 is feasible, and we can keep both the old and the new API available, we could give the various upstreams more time to port to the v2 API on their own time while allowing packages that require the v2 API today in testing now.
If that's not feasible, we'd have to go with option 1, read: update golang-goprotobuf to v1.4 breaking potentially over a hundred packages, have them removed from testing, work with upstreams to move to the new API and hope to "rescue" as many packages as possible before the next freeze. That, however, will be very painful as those packages might not be available even in unstable and a major inconvenience for everyone involved. I think we'd rather want to avoid this scenario.
Maybe there is another option I'm not seeing?