Feels like it would have been better to use a different delineating character instead of a slash to make it abundantly clear at a glance that it's effectively a major version tag and not a subpackage.
Other than that, seems relatively straightforward. Hope this is the last "new and completely different" attempt to tackle dependency management in Go.
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?
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
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
go get -u=patch
go get package@versionCheck out Russ's blog post series: https://research.swtch.com/vgo
[0]: https://futhark.readthedocs.io/en/latest/package-management....