The code would be different, presumably, but yes, there would be some duplication.
But what is the cost, exactly?
- If you’re the maintainer, then you want both versions, because you need to maintain both in parallel.
- If you’re the user, then you will likely never see the clone of the repo, and if you’re using modules or a package manager that prunes unused deps, you won’t even have the full clone.
- Because of the way Git works there’s no real cost to having exact copies of files in your tree.
- The actual size of the copied files is 764KB in this case, which is almost nothing at all (this web page is much, much larger).
In the longer term, either
- Go modules is on by default in the Go distitrbution, in which case you can switch to a
vNbranch with all thevNcode in the root of the repo. - You still want to support people who don’t use modules or use old versions of Go, in which case you could either add more
vNdirectories or create new repositories for the newer versions.
But the question you really have to ask yourself is: how many more major versions of this library do I really want to release? It’s not good for users (more churn), and it’s not good for you (more to maintain).
I think that the Go modules import path thing (enforcing the previous best practice) forces us to confront the real cost of making major releases. Just bumping a version number doesn’t feel like much, but having to think about a major version as a new, distinct thing that must be maintained and supported feels (appropriately) like a big deal.