Allow pre-releases when only used for one part of a range?
carolynvs opened this issue · comments
When I specify a range like so 1.0.0-0 - 2.0.0, pre-releases are not allowed, even though a pre-release is used for the lower range. Checking 1.0.0-alpha.1 against this range fails.
Adding a pre-release to the upper range is required to get it to work. Though I'd argue that the original range should have been sufficient. Otherwise it's pretty confusing that using an operator like ^1.0.0-0 allows pre-releases but the same constraint expressed as a range doesn't.
https://go.dev/play/p/0TKt6KChTKa
I expected that when a constraint is checked, if a prerelease is present on either end of the range, that pre-releases should be allowed.
While I'd love to see this corrected, if this is the intended behavior, it would have helped to have the readme explain how it applies to ranges as well as operators. Looking at the doc on the README, this is the text that lead me to believe the original constraint would work:
If you want to have it include pre-releases a simple solution is to include -0 to your range
Something like this would have been more clear:
If you want to have it include pre-releases a simple solution is to include -0 to operators, -0 to the lower part of a range and -z to the upper range. For example, ^1.0.0-0 or 1.0.0-0 - 2.0.0-z.
EDIT: I updated the suggested text since using -0 on the upper part of the range causes pre-releases to fail the check because nothing is lower than -0, so I'm guessing -z is the way to go?
Hmm this is getting awkward!
What I want to do is 1.0.0-alpha.4 - 1.0.0 which is represented internally as >= 1.0.0-alpha.4 <= 1.0.0 but due to the upper range not being a prerelease, that doesn't work.
Is this the best, or most brief, way of expressing that range?
1.0.0-alpha.4 - 1.0.0-z || 1.0.0
Given what's already documented, I would consider this to be a bug.
I'll work on getting a patch submitted then, thanks!