Protobuf: Please, release version v1.3.0

[mrzacarias]

People using this library are still using workarounds to be able to use the Proto3 and avoid https://github.com/golang/protobuf/issues/763

This issue was open in November, the last version is from August, we are currently 40 commits behind: https://github.com/golang/protobuf/compare/v1.2.0...master

When do the maintainers plan to release v1.3.0? May you please do this soon?

[spackard]

+1 Our official build vendors protobuf to v1.2.0, but some developers just go get the latest and have recently been burned by this.

[johanbrandhorst]

As mentioned in https://github.com/golang/protobuf/issues/763#issuecomment-442434870, a new release will not solve the underlying problem of using go get to install a newer version of protoc-gen-go than the vendored runtime is using. This is a fundamental problem in your build systems and in some way this error should encourage you to adopt appropriate versioning practices, as laid out in https://github.com/golang/protobuf/issues/763#issuecomment-442767135 and https://github.com/golang/protobuf/issues/763#issuecomment-452596424.

Is this not a dupe of #763?

[spackard]

It's not. You're not wrong about version control, but that doesn't change the fundamental question: It's been 5 months since the last official release. When do the maintainers plan to make another official release?

[johanbrandhorst]

Fair enough, the answer to that question is presumably "when it's ready", but I agree it would be nice to have a timeline.

[mrzacarias]

Thanks, @spackard, the 5 months delay and lack of timeline are the main reason for opening this issue.

Still, @johanbrandhorst, about the "right way" of versioning, which is it?
This https://github.com/golang/protobuf/issues/763#issuecomment-442767135 ?
This https://github.com/golang/protobuf/issues/763#issuecomment-442241577?
Maybe wait for 1.12 (https://github.com/golang/protobuf/issues/763#issuecomment-452596424) ?

See, that's the problem here: There's no "right way" yet, it's an ongoing discussion and a problem that is happening everywhere, hence why the majority of READMEs of go libraries are still referencing to go get -u as the main way of downloading dependencies.

I could pick and choose one of the workarounds and change my build system (did it already, by the way), but this is not a full solution, as everything is still moving (e.g. Go 1.12).

Meanwhile, would be nice for first party go libraries to keep their versioning working with go get -u, meaning keep master and the latest tag at least compatible. I highly suggest using gitflow workflow for it (i.e. having a develop branch to keep ongoing state and leave the master branch for the stable / latest release state.)

[johanbrandhorst]

Yes, having that kind of a workflow where master is always the latest release would help in this situation. Obviously that ship has sailed on this repo until the next release, but I'm sure it's something the maintainers could consider.

[neild]

I agree that we should leave master at the latest release. (We actually did that for a while, and stopped because it kept confusing people--but the confusion was preferable to what we have now.) We'll do that after we tag 1.3.0.

I think I'd like to see #784 make it in before tagging 1.3.0.

[mrzacarias]

@neild @johanbrandhorst @dsnet Sorry for nagging again, but this library is still maintained?

I opened this issue more than 30 days ago and it was recommended to only tag 1.3.0 after finishing #784 by @neild, but I don't see any open PRs regarding #784... Also, on the last 2~3 months we got only two features merged to master.

I'm honestly getting concerned, as we are basing a good amount of our production services over it. If it's not maintained anymore, there are any other similar libraries being developed that can be recommended?

[johanbrandhorst]

@mrzacarias This is the official Go implementation of protocol buffers, as supported by Google itself. It's certainly not abandoned. If there's been a lack of contributions it might be because a lot of work is going into the reworking of the go implementation. I wouldn't worry about the health of this project long term as (I assume) large parts of Googles internal infrastructure relies on it as well :).

[aofei]

Seriously, I'm even thinking, is it true that all developers who are using Go to write gRPC apps are naturally using those workarounds to do their work? Only me and the new gRPC users around me are crazy about this problem? I can't figure out why it was delayed for so long. This is really not like what the smart and efficient Google dev team in my mind will do.

Whenever there is a new gRPC user, I will tell him: If you're going to develop it with Go, then don't follow the official website documentation, otherwise you will definitely open Google to solve a bug that is not caused by you. Because Go modules will undoubtedly find the v1.2.0, and you will undoubtedly think that everything is fine... then you can't even run a simple "Hello, world"...

Sorry for my nagging words, I'm not a negative person, just once again someone around me was wasting my time because of #763.

So, please... at least make a milestone to comfort people?

[neild]

v1.3.0 has been tagged.