x/vgo: Semantic-versioning of modules without duplicating contents on-disk #24465
Comments
|
I believe the recommended way is to have a separate branch for each major version. Note that vgo doesn't actually require the |
|
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. |
|
Right, https://research.swtch.com/vgo-module (search for "major branches") is what you are looking for. This is a common point of confusion, and the eventual docs will make this very clear. |
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.
git status).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?
The text was updated successfully, but these errors were encountered: