Item — HN Reader

Fan boy? maybe. Informed? doesn't look like it:

> this is redundant because the local go.mod file already has the semantic version of all dependencies tracked

The whole point of having full version path in each file is to allow gradual upgrade to a new major version/a completely different package. Listen to Russ Cox go over this many times.

> Users of packages aren’t alerted about new major versions

Fair point.

> For the client to update, it’s not a simple path change in go.mod

It's a simple command:

gofmt -w -r '"github.com/logrusorgru/aurora" -> "github.com/logrusorgru/aurora/v3"' ./

> Maintainers should be able to increment the major version via Git tags.

Go is not tied to git or any other single SCM system. They can however be pragmatic about this.

> I get why these rules exist, and I think they are great for large open projects

You either don't, or you think that smaller/trivial project's requirements somehow take priority over larger ones. There are plenty of toy/application specific/scripting programming languages built to be used to write a few hundred lines or glue things together. Go specifically and repeatedly states that it's aimed at large, distributed and long term projects with lots of changes over time and many contributors. You know that going in. So you're criticizing (poorly I might add) the very notions that this language is built upon! This is like criticizing an industrial kitchen equipment for not having pretty colors and curvy shapes to match your home decor.

> The whole point of having full version path in each file is to allow gradual upgrade to a new major version/a completely different package. Listen to Russ Cox go over this many times.

That only works if v2 of the library is crazy enough to keep all of the v1 apis around as well. Otherwise, when I switch version the old import path stops working.

> gofmt -w -r '"github.com/logrusorgru/aurora" -> "github.com/logrusorgru/aurora/v3"' ./

Cool. Does that also cleanup git history so that I don't have to look at hundreds of files which needlessly got changed?

> That only works if v2 of the library is crazy enough to keep all of the v1 apis around as well. Otherwise, when I switch version the old import path stops working.

Gradual upgrade, as in you can update a single file to use the next major version. Not sure what you’re on about.

> hundreds of files which needlessly got changed

If you have hundreds of files and upgrading to a new major version all at once, you’re creating the exact risk that Go is trying to mitigate.