Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

x/vgo: Semantic-versioning of modules without duplicating contents on-disk #24465

Closed
ChimeraCoder opened this issue Mar 20, 2018 · 3 comments

Comments

@ChimeraCoder
Copy link
Contributor

commented Mar 20, 2018

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?

@gopherbot gopherbot added this to the vgo milestone Mar 20, 2018

@huguesb

This comment has been minimized.

Copy link
Contributor

commented Mar 20, 2018

I believe the recommended way is to have a separate branch for each major version. Note that vgo doesn't actually require the /vX/ prefix to be present in the repository itself, only in the import path and go.mod

See https://research.swtch.com/vgo-module

@ChimeraCoder

This comment has been minimized.

Copy link
Contributor Author

commented Mar 26, 2018

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.

@rsc

This comment has been minimized.

Copy link
Contributor

commented Mar 27, 2018

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.

@rsc rsc closed this Mar 27, 2018

@golang golang locked and limited conversation to collaborators Mar 27, 2019

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
4 participants
You can’t perform that action at this time.