A new Go API for Protocol Buffers
blog.golang.org
A new Go API for Protocol Buffers
1–10 of 100 posts
Re: A new Go API for Protocol Buffers
#2Interesting that even Google decided to do complex versioning gymnastics and introduce a new namespace in order to avoid how `go mod` adds the version as a path component.
Re: A new Go API for Protocol Buffers
#3Interesting that even Google decided to do complex versioning gymnastics and introduce a new namespace in order to avoid how `go mod` adds the version as a path component.
Nah, we just really wanted to stop using an import path tied to a specific hosting provider. Once we decided to change to an entirely different path, we waffled a lot over whether to tag it v1 or v2. There were arguments for and against either, so we eventually picked one and went with it.
Re: A new Go API for Protocol Buffers
#4> The github.com/golang/protobuf module is APIv1.
> The google.golang.org/protobuf module is APIv2. We have taken advantage of the need to change the import path to switch to one that is not tied to a specific hosting provider.
That's such a weird choice, and will be quite confusing. Now every time you see protobuf being imported, you have to be sure to pay extra attention to the domain used, and correctly remember which one is v1 or v2. If only go modules established a clear way to differentiate API versions using the import path!
Re: A new Go API for Protocol Buffers
#5Interesting that even Google decided to do complex versioning gymnastics and introduce a new namespace in order to avoid how `go mod` adds the version as a path component.
Nah, we just really wanted to stop using an import path tied to a specific hosting provider. Once we decided to change to an entirely different path, we waffled a lot over whether to tag it v1 or v2. There were arguments for and against either, so we eventually picked one and went with it.
Sure, but why version the new package as v1.20 instead of v2.x?
Re: A new Go API for Protocol Buffers
#6Interesting that even Google decided to do complex versioning gymnastics and introduce a new namespace in order to avoid how `go mod` adds the version as a path component.
Nah, we just really wanted to stop using an import path tied to a specific hosting provider. Once we decided to change to an entirely different path, we waffled a lot over whether to tag it v1 or v2. There were arguments for and against either, so we eventually picked one and went with it.
That makes the most sense, and throws a great seasoning of context on that decision. Thanks for providing that here.
Re: A new Go API for Protocol Buffers
#7Earlier quoted context omitted.
Nah, we just really wanted to stop using an import path tied to a specific hosting provider. Once we decided to change to an entirely different path, we waffled a lot over whether to tag it v1 or v2. There were arguments for and against either, so we eventually picked one and went with it.
Sure, but why version the new package as v1.20 instead of v2.x?
Because they would had to add a `/v2` suffix to the import path and seems like they didn't wanted to add that. The question is, why is this not released as v1.0.0 then? Still trying to understand the reasoning for this.
Re: A new Go API for Protocol Buffers
#8Earlier quoted context omitted.
Sure, but why version the new package as v1.20 instead of v2.x?
Because they would had to add a `/v2` suffix to the import path and seems like they didn't wanted to add that. The question is, why is this not released as v1.0.0 then? Still trying to understand the reasoning for this.
Oh I didn't realize that was mandatory. I thought omitting v2 from the path was sort of OK until you explained this. Now it just seems wrong.
Re: A new Go API for Protocol Buffers
#9Earlier quoted context omitted.
Sure, but why version the new package as v1.20 instead of v2.x?
Because they would had to add a `/v2` suffix to the import path and seems like they didn't wanted to add that. The question is, why is this not released as v1.0.0 then? Still trying to understand the reasoning for this.
Reasoning went something like this:
We could tag the new API v2:
+ Makes the "v1" and "v2" distinction very clear in the import path.
- Confusing: google.golang.org/protobuf@v1 doesn't exist, but v2 does.
- In ten years, hopefully nobody cares about the old github.com/golang/protobuf and the confusion is gone.
We could tag the new API v1:
- Less visually distinct in the import path.
+ Seems to make sense for the first version of google.golang.org/protobuf to be a v1.
+ If we decide it was a terrible idea, it's easier to go from v1 to v2 than to roll back from v2 to v1.
We waffled back and forth for quite a while on this, and eventually decided that the first version of google.golang.org/protobuf would be a v1. Then as we got closer to release (but with a certain amount of usage of v0 in the wild), we decided not to second-guess that decision but to start with a version that wouldn't overlap with any version of github.com/golang/protobuf to avoid confusion when someone reports a bug in "v1.0.1".
Maybe it was the wrong choice. If it was the worst choice we've made in the new API, I'll be happy!
Re: A new Go API for Protocol Buffers
#10> The github.com/golang/protobuf module is APIv1. > The google.golang.org/protobuf module is APIv2. We have taken advantage of the need to change the import path to switch to one that is not tied to a specific hosting provider. That's such a weird choice, and will be quite confusing. Now every time you see protobuf being imported, you have to be sure to pay extra attention to the domain used, and correctly remember w…
> If only go modules established a clear way to differentiate API versions using the import path!
It did, they just chose not to follow it :/ I wonder what rsc thinks about this decisions