Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow pre-releases when only used for one part of a range? #177

Open
carolynvs opened this issue Jul 21, 2022 · 6 comments · May be fixed by #184
Open

Allow pre-releases when only used for one part of a range? #177

carolynvs opened this issue Jul 21, 2022 · 6 comments · May be fixed by #184
Labels

Comments

@carolynvs
Copy link

carolynvs commented Jul 21, 2022

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?

@carolynvs
Copy link
Author

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 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

@mattfarina mattfarina added the bug label Aug 9, 2022
@mattfarina
Copy link
Member

Given what's already documented, I would consider this to be a bug.

@carolynvs
Copy link
Author

I'll work on getting a patch submitted then, thanks! 👍

carolynvs added a commit to carolynvs/semver that referenced this issue Aug 9, 2022
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>
@carolynvs carolynvs linked a pull request Aug 9, 2022 that will close this issue
carolynvs added a commit to carolynvs/semver that referenced this issue Aug 9, 2022
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>
@carolynvs
Copy link
Author

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.

@jelemux
Copy link

jelemux commented Oct 2, 2023

Just ran into this problem in a project. Would be cool if the fix in #184 could be merged soon.

@yhl25
Copy link

yhl25 commented Sep 16, 2024

Just ran into the same problem on my project. Can can get it fixed soon?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants