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....
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.