-
Notifications
You must be signed in to change notification settings - Fork 1
Allows non-semver versions #123
Comments
@deadok22 as I understand this issue, the requirements are that users will be able to specify versions in /modules/new in a way similar to
I think this is difficult, since there's no single way of resolving what a pseudo version is ; non-github may behave differently. Further, I think the main use case is just adding a pre-modules repo as a dependency, so I'd like to make it easier to just do that. /mods/find brings us close, but has a few shortcomings. I'm going to try fixing those in #173. Please correct me if I misunderstood what this issue is about. |
@ovesh apologies for a delayed response - I was on vacation. Yes, the idea is to have the same UX
The algorithm for generating a pseudo-version given a version string is kind of described here (and, yes, it's not exactly simple :) ).
Why would version resolution have anything to do with a particular repository hosting platform? (I haven't read the |
I discussed this offline with @deadok22. The request here is that
I'm going to look at |
Modprox should only add semver-versions or pseudo-versions of modules.
I think the behavior should be similar to that of
go get
: resolve a non-semver tag to a revision and add the module by its pseudo-version.See this and this for more info on pseudo-version handling.
The text was updated successfully, but these errors were encountered: