Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
x/vgo: Semantic-versioning of modules without duplicating contents on-disk #24465
vgo is based on semantic versioning. The introductory post for vgo proposes using paths to separate versions, and this is fleshed out in more detail in the Versioned Go Modules proposal.
This has a clear benefit: the import path indicates the required major version. However, because import paths map 1-1 to paths on-disk, this implies that issuing a new major version will require duplicating code on-disk.
Git, fortunately, will duplicate identical files, so the size of the repository for network operations will not be affected too much, but directory size still has an impact on the performance of basic git operations (e.g.
The project I work on for my day job, Veneur, operates on a six-week release cycle, with a new major version every six weeks (similar to Chrome and Firefox). That's about 9 releases per year. If the code has to be duplicated in full nine times per year, that adds up pretty quickly to a non-trivial amount of disk space.
Is there a way to implement semantic versioning for modules that doesn't impact disk utilization?
Ah! And I assume separate tags will be supported as well (since git unannotated tags are fundamentally the same as branches)?
If that's the case, I'd recommend updating the language in the proposal to clarify this, then - I read it as requiring it in the directory, and from talking to others, it sounds like I wasn't the only one confused by that point.