Hacker News Reader

> 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.

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).

Indeed, tying the name of a package to a hosting provider is a bad idea! That's why we changed to an import path which isn't tied to one. google.golang.org/protobuf is not tied to any particular provider, and we can redirect it wherever we want.

See "go help importpath" for details on how this works.

> - Confusing: google.golang.org/protobuf@v1 doesn't exist, but v2 does.

> 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?

Because the Go package name is github.com/golang/protobuf. Serving it from a different address is already a breaking change.

When I read the article, my brain passed right over the different domain names; the two are even the exact same number of characters, set in a monospace font, and my brain passes right over the domain of golang imports to the end of the path. That's where the interesting bit is (usually!)

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

I think you’re overestimating how much people pay attention to the body part of the import paths. Since there have been a quite few projects that implemented a sort of redirect (i.e. ‘vanity’ imports [0]) most people’s eyes just glaze over the small change in the URL.

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/

What are you going to do for APIv3?

Version it as google.golang.org@v2? google.golang.org@v3 (but @v2 doesn't exist)? Release an @v2 which is identical to @v1?

We used up our breaking change budget for the next decade with this release, so we'll think about it in 2030.

Admit it, once Windows 22 is out the door, protobuf 1.22 is shippin' as well! Yieehaaw!

Rust .22 with breaking changes, will be breaking 4 years after that as well!

Can you explain why it's not possible to create `google.golang.org/protobuf@v1` retroactively?

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?

Thanks for the all the work. And I hope my rant doesn't come something as a bad. But I truly believe the versioning along with the import path is confusing. I hope the team goes over the versioning again and come up with something that makes more sense.

When you were waffling back on forth on the decision, did anyone note that “re-using v1 is a weird choice and is going to be the main thing people talk about”?

> - Confusing: google.golang.org/protobuf@v1 doesn't exist, but v2 does.

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.

You could give google.golang.org/protobuf@v1 an //importpath to the github package, so go would warn people about it.