Interesting 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.
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!
I find this a super confusing and unintuitive choice, but I suppose it's too late for changing it now.
Sincerely, an othwerwise mostly happy protobuf user
Version it as google.golang.org@v2? google.golang.org@v3 (but @v2 doesn't exist)? Release an @v2 which is identical to @v1?
Rust .22 with breaking changes, will be breaking 4 years after that as well!
This seems like a good example why tying the name of the package in the code with the place where it can be downloaded was a very bad idea. Simply changing hosting providers is now a backwards compatibility break for your clients.
If Go imports didn't work this way, you could have simply offered the old v1 from both github.com and google.golang.org, and used a clear v2 for the v2. Sure , you would have similar problems if you wanted to change the logical package structure for some reason (say, when an open-source package moves to a different organization), but that is a much rarer case than switching code repos.
However, given that that ship has probably long sailed, you probably picked the right choice.
I would also note that v2 in the import path feels a bit strange, since it makes users of the newest code need to know about the history of the package, but there are also clear advantages which probably out-weigh this (I believe this is absolutely not the case for the decision to include the hosting provider in the import path).
See "go help importpath" for details on how this works.
> google.golang.org/protobuf is not tied to any particular provider, and we can redirect it wherever we want.
I agree, this is confusing. Why doesn't google.golang.org/protobuf@v1 return what's at github.com/golang/protobuf, then, if only to provide a tidy answer for those who wonder what v1 looked like?
I would strongly suggest using /v2 at the end. /v1 not existing on *.golang.org is not a problem in practice, but if it ends up one you could just set that up as a vanity import pointing to github.com for the old version.
[0] https://sagikazarmark.hu/blog/vanity-import-paths-in-go/
Also:
> In ten years, hopefully nobody cares about the old github.com/golang/protobuf and the confusion is gone.
is the corollary that this change will cause 10 years of confusion?
This would not be confusing at all. The UUID package I use just skipped from major version 3 to major version 7 to avoid confusion with UUIDv4, UUIDv5 and a possibe UUIDv6. It was well-documented, and even if it wasn't, the upgrade was absolutely painless, as it would have been either way.
e.g. github is now owned by Microsoft and it's a little awkward.
If Google won out on their attempt to buy Github, they wouldn't wouldn't be talking about a "specific hosting provider".
Though it's a little weird that people take this at face value, when the majority of the userbase was questioning this since the first release.
What if those things move to different domains, or different directory structures? Wouldn't that break every Go program that depends on them?
I've been using Java, Python, and Ruby for a while. They all have various pain points for managing dependencies but they do get one thing right: packages have names and versions, names are opaque strings that are not coupled to a particular hosting provider, and they don't care what directory on my laptop I use to store my dependencies and my code.
The Go dependency model seems like a real step backwards in usability and maintenance. It's like they are forcing one software org's standards on the rest of us. We don't all work at Google! Just let us depend on things that have names and version numbers!
Are there any plans to fix this for the whole language, for others as well? i.e. use namespaces, module names in the source but move the actual github.com, google.com or geocities.com URLs outside.