Comments (8)
@stapelberg, we try to support one add'l release of Go, so we'd appreciate pinning no more recent than Go 1.20, just so we can continue to support Go 1.20 for our own libraries and be able to update to the latest/next release of protobuf-go.
I might also point out that the other major Go libraries, like those in golang.org/x/...
all seem to pin 1.18, which a few pinning 1.19. If those packages provide broader support, it seems like it would be valuable for Protobuf to provide the same board support.
Any change you could tweak the recent change to step it back to 1.20 from 1.21?
from protobuf.
FWIW, our desire to support one add'l version back mirrors Amazon's support policy with its AWS client libraries for Go: https://github.com/aws/aws-sdk-go-v2?tab=readme-ov-file#go-version-support-policy
I think it is a pretty common stance to want to support one or two prior versions of Go. And since protobuf-go is such a heavily used dependency, it would be a much friendlier stance for projects with dependencies on protobuf (even indirect/transitive) to provide a little more room with regards to the support window.
from protobuf.
@jhump Thanks for your comment. I want to address the second paragraph in #1613 (comment): the golang.org/x/... modules are only tested with the 2 most recent versions which are supported per Go's policy, not older. Their go
directive values are not a good source to infer support from. That directive hasn't been updated regularly to use newer semantics because it has been a manual process thus far, last done holistically in golang/go#60268. As the original issue points out, we plan to work towards automating that process.
The Go project officially supports only the 2 most recent major versions as written down at https://go.dev/doc/devel/release#policy, and the Go proposal process would be the best place to suggest a change to that policy. Thanks.
from protobuf.
I noticed that Go is, unfortunately, missing from Protobuf's version support policy listed here:
https://protobuf.dev/support/version-support/
Dropping/changing the support minimums for Go versions feels like a breaking change that would merit a major release to signal such a change. Is that the plan?
Reviewing the compatibility statements of the project README:
https://github.com/golang/protobuf?tab=readme-ov-file#compatibility
This change doesn't seem to reflect any of the stated valid reasons for a breaking change. Was this announced to the mailing list? I believe this requires a 6-month heads-up per the stated policy.
I appreciate the interest in following the supported policies of Go releases, but as far as I can tell, this isn't actually something that is inherently required or guaranteed to be the case for this project. Am I misunderstanding?
from protobuf.
Thanks for your feedback.
@jhump We can consider adding support for one extra deprecated Go version (Go 1.20 in this case) if this really helps large parts of the ecosystem. We wouldn’t want to go back any further than one deprecated version, though.
Before we make that change, can you explain where the motivation comes from, both in the AWS case (do AWS users have trouble updating to newer Go versions?) and in the buf.build case (are your customers actually reliant on deprecated Go versions?), just so that we can better understand and justify this extra work/delay?
Also, can you explain if this situation is expected to improve thanks to the toolchain management features of Go 1.21+, or are you expecting to be perpetually behind the support window?
@perezd No, I don’t think it’s reasonable to treat a language version bump as a breaking change in Go modules. Bumping to v3 will cause incredible ecosystem churn. Ask around among buf.build folks regarding the v1→v2 transition. IIRC, it was someone from buf.build who even asked us to never do a major bump like that ever again.
from protobuf.
No, I don’t think it’s reasonable to treat a language version bump as a breaking change in Go modules.
I understand your position. Thanks for clarifying. My main concern was if people are upgrading their dependencies and (often transitively) protobuf causes their builds to break due to tightening of the supported version window suddenly, would that reflect poorly on the project? It's not totally clear from reading the Protobuf change policy or your docs when someone should expect or be able to plan for changes like this that impact their deployments.
Edit: GCP versions policy refers to three most recent versions fwiw: https://cloud.google.com/go/getting-started/supported-go-versions
from protobuf.
Since Protobuf is so heavily used by the GCP Go libraries, I would think that page that @perezd linked above would weigh heavily in decisions like this.
Will GCP be okay with updating their policy or with just not pulling in protobuf-go updates for a few months?
I'm not sure how Amazon and GCP landed on these policies. We landed on it just because, in practice, updating the toolchain every 6 months or every year can be painful. While it might usually be painless and drama-free (that's obviously the Go team's intent), there could be other logistics to consider (like if an organization has a monorepo that doesn't support multiple versions of the toolchain, in which case extra testing and coordination is necessary for each update, perhaps from a dedicated developer productivity team). While the updates have recently been very smooth, I certainly remember past Go upgrades that were not (like updating to Go 1.7 and then Go 1.13 at past employer).
The toolchain improvements in Go 1.21 may indeed change our thinking on this. But since we haven't updated our own libraries to that point yet (they all still support Go 1.20), we haven't given it as much thought.
from protobuf.
Thanks for the details, folks. I agree that we should align with large users such as the GCP Go libraries.
It might make sense to revisit this once toolchain management is used more in practice. When revisiting, we should first figure out if libraries like GCP Go and AWS can be aligned with Go’s support policy (only 2 versions) before updating Go Protobuf.
from protobuf.
Related Issues (20)
- go_features.proto has incorrect package and error-prone file path HOT 5
- Tracking issue: Fully Lazy Extension decoding HOT 7
- feature: Generate test client / `bufconn` constructors HOT 4
- v1.33.0 breaks bazel build HOT 14
- Reflection: protopath parsing and path+message access HOT 7
- Proposal: Add `Override` mode to `proto.Merge` HOT 2
- editions: maps are incorrectly serialized if file has default message encoding of DELIMITED HOT 8
- protodesc: too strict about proto3 field names when creating descriptors from FileDescriptorProto
- undefined: descriptorpb.Default_FileOptions_PhpGenericServices HOT 2
- `ProtoReflect().GetUnknown()` Not Working HOT 4
- Editions language feature: (pb.go).struct_tag HOT 11
- encoding/protojson: handling google.protobuf.Empty HOT 15
- Make M option overwrite `option go_package` in the `.proto` file (as opposed to return an error) HOT 5
- related to #1054 and similar "plugin output is unparseable" errors HOT 4
- Random 0xfeff / ZERO WIDTH NO-BREAK SPACE being added to returned string values HOT 3
- custom options doesn't seem to work for protobuf map fields HOT 2
- Can protobuf provide tags for customized message generated fields? HOT 2
- encoding/protojson: unmarshalBytes assumes no padding if byte string length is not divisible by 4 HOT 9
- Service crash caused by encoding HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from protobuf.