-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Please, release version v1.3.0 #786
Comments
+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. |
As mentioned in #763 (comment), a new release will not solve the underlying problem of using Is this not a dupe of #763? |
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? |
Fair enough, the answer to that question is presumably "when it's ready", but I agree it would be nice to have a timeline. |
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? 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 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 |
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. |
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. |
@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? |
@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 :). |
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 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? |
v1.3.0 has been tagged. |
People using this library are still using workarounds to be able to use the Proto3 and avoid #763
This issue was open in November, the last version is from August, we are currently 40 commits behind: v1.2.0...master
When do the maintainers plan to release v1.3.0? May you please do this soon?
The text was updated successfully, but these errors were encountered: