aurora

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

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 e