Allow pre-releases when only used for one part of a range? #177
Comments
|
Hmm this is getting awkward! 😅 I'm trying to allow a prerelease on the lower bound and a stable release on the upper. What I want to do is Is this the best, or most brief, way of expressing that range?
|
|
Given what's already documented, I would consider this to be a bug. |
|
I'll work on getting a patch submitted then, thanks! 👍 |
Currently, when a range uses a pre-release, such as 1.0.0-alpha.1 - 1.1.0, all pre-release versions are being rejected when the constraint is checked because the upper part of the range does include a pre-release. For example, 1.0.0-alpha.2 should match that range, but it is rejected right now. I have updated how we evaluate constraints so that it checks whether a constraint part uses pre-releases OR the larger constraint range that it is part of uses a pre-release. When either part of a range uses a pre-release, the entire range should allow pre-release versions. Fixes Masterminds#177 Signed-off-by: Carolyn Van Slyck <me@carolynvanslyck.com>
Currently, when a range uses a pre-release, such as 1.0.0-alpha.1 - 1.1.0, all pre-release versions are being rejected when the constraint is checked because the upper part of the range does not include a pre-release. For example, 1.0.0-alpha.2 should match that range, but it is rejected right now. I have updated how we evaluate constraints so that it checks whether a constraint part uses pre-releases OR the larger constraint range that it is part of uses a pre-release. When either part of a range uses a pre-release, the entire range should allow pre-release versions. Fixes Masterminds#177 Signed-off-by: Carolyn Van Slyck <me@carolynvanslyck.com>
|
I have a working fix that I'll update the PR with shortly. After merging with master I noticed a regression in parsing constraints that use a space instead of a comma to separate the constraint parts, so I'll open an issue for that too. |
|
Just ran into this problem in a project. Would be cool if the fix in #184 could be merged soon. |
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. Checking1.0.0-alpha.1against 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 rangeSomething 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?
The text was updated successfully, but these errors were encountered: