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

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.