3 ms·

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

by neild 7y ago

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.

jzwinck 7y ago
Sure, but why version the new package as v1.20 instead of v2.x?
- farslan 7y ago
  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.
  - jzwinck 7y ago
    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.
  - neild 7y ago
    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!
    - farslan 7y ago
      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.
    - llimllib 7y ago
      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
    - rverghese 7y ago
      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?
      - neild 7y ago
        We used up our breaking change budget for the next decade with this release, so we'll think about it in 2030.
        deleted 7y ago
        [deleted]
        loopz 7y ago
        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!
    - bouk 7y ago
      You could give google.golang.org/protobuf@v1 an //importpath to the github package, so go would warn people about it.
ifoundthetao 7y ago
That makes the most sense, and throws a great seasoning of context on that decision. Thanks for providing that here.
endorphone 7y ago
"we just really wanted to stop using an import path tied to a specific hosting provider" 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.
paulddraper 7y ago
So both old and new are available through the new domain?
twblalock 7y ago
The whole idea of tying image names to hosting provider urls or other kinds of locators was probably a bad idea. 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!
zerr 7y ago
> we just really wanted to stop using an import path tied to a specific hosting provider 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.
- yencabulator 7y ago
  The support has been there for a long time. `go help importpath`

by neild 7y ago

jzwinck 7y ago

Sure, but why version the new package as v1.20 instead of v2.x?

farslan 7y ago
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.
- jzwinck 7y ago
  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.
- neild 7y ago
  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!
  - farslan 7y ago
    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.
  - llimllib 7y ago
    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
  - rverghese 7y ago
    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?
    - neild 7y ago
      We used up our breaking change budget for the next decade with this release, so we'll think about it in 2030.
      - deleted 7y ago
        [deleted]
      - loopz 7y ago
        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!
  - bouk 7y ago
    You could give google.golang.org/protobuf@v1 an //importpath to the github package, so go would warn people about it.

ifoundthetao 7y ago

That makes the most sense, and throws a great seasoning of context on that decision. Thanks for providing that here.

endorphone 7y ago

"we just really wanted to stop using an import path tied to a specific hosting provider" 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.

paulddraper 7y ago

So both old and new are available through the new domain?

twblalock 7y ago

The whole idea of tying image names to hosting provider urls or other kinds of locators was probably a bad idea. 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!

zerr 7y ago

> we just really wanted to stop using an import path tied to a specific hosting provider 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.

yencabulator 7y ago
The support has been there for a long time. `go help importpath`