You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have a use case where I need to transform a bunch of VersionReqs to ranges, so that a much simpler downstream matcher can then operate on ranges and find if a given version falls within a given range or not.
The problem is that the ranges field on VersionReq is private, along with the Range struct. I'm using a patched copy with those fields made public for prototyping, but I'd like to arrive to a long-term solution that does not require patching.
Should I open a pull request making Range a public struct? Or do you prefer to keep those fields that private, but uplift the entire range conversion logic into semver? Or is there some other approach that I should take?
For context, I just want to know the intervals, and semver's version selection logic around pre-releases would be actively harmful (see #172).
The text was updated successfully, but these errors were encountered:
Turns out that making this field public and in any way useful requires exposing a lot of internals. My first thought was to serialize the list of ranges to string and use semver_parser to get it back as public structs, but I can't find a sane way to turn the constraints into strings that can be fed to semver_parser either.
I have a use case where I need to transform a bunch of
VersionReq
s to ranges, so that a much simpler downstream matcher can then operate on ranges and find if a given version falls within a given range or not.The problem is that the
ranges
field onVersionReq
is private, along with theRange
struct. I'm using a patched copy with those fields made public for prototyping, but I'd like to arrive to a long-term solution that does not require patching.Should I open a pull request making Range a public struct? Or do you prefer to keep those fields that private, but uplift the entire range conversion logic into semver? Or is there some other approach that I should take?
For context, I just want to know the intervals, and semver's version selection logic around pre-releases would be actively harmful (see #172).
The text was updated successfully, but these errors were encountered: