On Fri, Jan 8, 2021 at 11:17 PM Alberto Bertogli <albert...@blitiri.com.ar> wrote: > > On Thu, Jan 07, 2021 at 11:12:24PM +0800, Shengjing Zhu wrote: > >On Thu, Jan 7, 2021 at 10:59 PM Alberto Bertogli > ><albert...@blitiri.com.ar> wrote: > >> But those issues are not made worse by allowing golang-google-protobuf > >> to go in, right? > >> > > > >Let golang-google-protobuf go in is one thing, it's not difficult. > >However without golang-goprotobuf 1.4.x it's not useful currently. But > >it will be changed if upstream has switched to golang-google-protobuf > >only. > > But IIUC that's what foka@'s lastest changes do - now the two packages > are independent so golang-google-protobuf can go in? > > This would unblock: > 1) Some upstream packages that have upgraded to the new library and are > using pregenerated pb.go without the dependency. > 2) Packages that have moved/want to move to the new library and generate > pb.go as part of the build (without needing grpc). > > And no packages are forced into anything, since upstream needs to do the > update explicitly anyway, the ones using golang-goprotobuf will continue > to function just fine. > > I understand not all problems are fixed and some things remain, but it > seems it'd be a step in the right direction since at least some packages > will be able to move forward, without causing any new > complications/regressions. > > Or am I missing something? >
You are right. The only concern from my side is the usefulness of golang-google-protobuf without upgrading golang-goprotobuf to 1.4. If some packages are already ready for using golang-google-protobuf solely, sure we should try. -- Shengjing Zhu
