Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
In CL 122400 @bcmills pointed out that we haven't defined what
means for example v1.0.0. Obviously it must mean you get elucidation v1.1.0 not v1.2.0. But that's not documented nor implemented.
Bryan also raised the question of whether to allow
to make it completely unavailable. Probably we should.
Part of the problem here is that there are two different possible meanings for a “wildcard
One is, “
The other — from what I can tell, by far the more common case — is “once you have selected a version of this module, pretend that this replacement is an even higher version and use it instead”. That's the
Adding my own brain-dump to the topic, mixed with some thoughts on adjacent issues (who said "multi-module repos"?).
Supporting this would definitely make sense for me. It would provide native support for (security) blacklisting of specific hosts and I would even extend it to not necessarily be a module path but more a pattern:
It does seems sensible to make this result in replacing
This ties somewhat back to my note about the
The related use-case, although definitely valid, is not one I have personally encountered much yet. In practice this particular
One example is the way Kubernetes uses it to achieve the continuous pinning of versions for their dependencies. They rely on the wildcard version but they could work as well with the version-specific statement as well, but this would complicate their already complex automation around module-maintenance even further.
Another similar and frequent use is when migrating (old) projects to modules, whether they have been using third-party dependency management or simply relying on GOPATH. Projects frequently encounter the issue that the dependency graph they rely on for building is not compatible with MVS. Migration thus generally means adding a
NB: I am not advocating that the way Kubernetes uses