3 ms·
Particularly the fact that it only applies after the second version. If we're going to require /v2, /v3, etc - shouldn't we also require /v1 for the first? Als
by BillinghamJ 8y ago
Particularly the fact that it only applies after the second version. If we're going to require /v2, /v3, etc - shouldn't we also require /v1 for the first?
Also it's unclear how initial development (as per server) is to be handled. If the first few versions are v0.1.0, v0.2.0, etc. - how are these handled on the import paths.
What if a package URL actually contains "/v2" at the end, but this isn't actually referring to the version and should be used when fetching the package. Seems very odd. Agree that it should have been more like "@2".
What if you want to include two different minor versions, for example, as you can include two different major ones. Is that possible/allowed?
- cube2222 8y agoRequiring v1 would break backwards compatibility. If you create a new library, feel free to do that. The point is to treat different major versions as different packages, enough obviously lets you use multiple major versions in your project. v0 and v1 are treated as the same package, you're supposed to use v0 as long as you're adapting to vgo / potentially doing breaking changes and use v1 when you know you'll keep a stability guarantee. As I mentioned in the sibling comment, it's all described in Russ's blog post series, long, but well worth the read: https://research.swtch.com/vgo https://research.swtch.com/vgo
- pests 8y ago> If the first few versions are v0.1.0, v0.2.0, etc. - how are these handled on the import paths. This was answered in the post. It's handled in the mod file and not via import path. Import path only changes when there is breaking changes, ie: a major bump and a new /v# for the import path. Upgrade minor or patch to most recent: go get -u Upgrade patch to most recent: go get -u=patch Upgrade to specific version: go get package@version