Hacker News Reader

Comment by dgellow | Hacker News Reader

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

View on HN

The goal of issuing a major version is to create a separate package namespace so it can be imported concurrently to other major versions. By treating major versions as different packages, it creates efficiencies in VCS history and common namespace.

However, the goal is to create a new package name that can be concurrently imported with previous versions. Everything else is just method. Don't confuse the goal with the method.

People care about versions. If it’s harder or more confusing to understand what version you’re on, that’s more than “just method”. Otherwise we’d just use UUIDs for package names and call it a day.

Julia uses uuids masked with name.

> 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

Rsc?

Russ Cox https://news.ycombinator.com/user?id=rsc

Thanks!

I know, that sentence was meant to be ironic :)

Then you see the version imported being v1.X where X>20 and of course that makes it obvious that it’s v2?

Are version numbers 2.0 and higher explicitly banned?

Edit: found an explanation further down (spoiler: not a very good one but a very go one).

It's Google.

Valid versions are in the 0 < x < 1.0 range.

I believe this is discussed and decided quite early on: https://docs.google.com/document/d/19kfhro7-CnBdFqFk7l4_Hmwa...

>According to the Import Compatiability Rule for versioned Go, this implies that the new proto package must have a new import path. Since "github.com/protobuf/proto/v2" will incur great confusion with the proto2 syntax, we may take this time to use an import path like "google.golang.org/proto" (similar to how gRPC lives at "google.golang.org/grpc").

Random question, but how did they get the source code highlighting in that doc?

Code Blocks addong from G Suit Market (new doco -> addons -> Install -> Code Blocks)

They did get one benefit from this choice:

> the version number alone should be enough to unambiguously differentiate between APIv1 and APIv2.

...which is how version numbers normally work. They've made a big breaking change in a 1.X release, so it isn't semver, but that isn't the end of the world. It works around having to put the major version number in the import path too, so really it works like most other non-Go, non-semver, projects.

I've seen many people append a version to the package name. So they could have done `protobuf.v2` (granted the original would be missing a version but still, at least this is more explicit)

Would be nice if they would just make packages.golang.org sorta how Python has PyPI, Rust has Crates.IO and so on... They can just redirect to relevant repos...

Reply on news.ycombinator.com