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

Support tilde in semver constraints #172

Open
voor opened this issue Jul 11, 2022 · 5 comments
Open

Support tilde in semver constraints #172

voor opened this issue Jul 11, 2022 · 5 comments
Labels
carvel-accepted This issue should be considered for future work and that the triage process has been completed enhancement This issue is a feature request priority/important-longterm Important over the long term, but may not be staffed and/or may need multiple releases to complete.

Comments

@voor
Copy link

voor commented Jul 11, 2022

Describe the problem/challenge you have
I want to support 1.2.x for a given version, including pre-releases, but given something like this:

1.1.1
1.1.2
1.2.0
1.2.10-build.1
1.2.10
1.2.100-build.20
1.2.100
1.3.0-build.1
1.3.0-build.2

It's hard to figure out where to put the <, since 1.3.0-build.x is considered less than 1.3.0

vendir tools sort-semver -v "1.1.1 1.1.2 1.2.0 1.2.10-build.1 1.2.10 1.2.100-build.20 1.2.100 1.3.0-build.1 1.3.0-build.2" -c "<1.3.0" --prerelease --prerelease-identifier "build"
Versions

Version  
1.1.1  
1.1.2  
1.2.0  
1.2.10-build.1  
1.2.10  
1.2.100-build.20  
1.2.100  
1.3.0-build.1  
1.3.0-build.2  

Highest version: 1.3.0-build.2

Succeeded

Changing it to something like:

vendir tools sort-semver -v "1.1.1 1.1.2 1.2.0 1.2.10-build.1 1.2.10 1.2.100-build.20 1.2.100 1.3.0-build.1 1.3.0-build.2" -c "<1.2.10" --prerelease --prerelease-identifier "build"

Causes you to miss the high numbers of 1.2.x.

Describe the solution you'd like
~ exists in several upstream semver libraries, so you can do something like:

~1.2

And it'll work for all patch versions of 1.2, but exclude anything in 1.3 or higher.

Anything else you would like to add:
While this is extremely unlikely in the exemplified upstream product (TAP), I wanted to capture this in case the scenario becomes increasingly likely. Pretty sure my use case is satisified by just picking something like 1000 for the patch release (I'm actually just using 1.2.9 now since that also seems likely to work)


Vote on this request

This is an invitation to the community to vote on issues, to help us prioritize our backlog. Use the "smiley face" up to the right of this comment to vote.

👍 "I would like to see this addressed as soon as possible"
👎 "There are other more important things to focus on right now"

We are also happy to receive and review Pull Requests if you want to help working on this issue.

@voor voor added carvel-triage This issue has not yet been reviewed for validity enhancement This issue is a feature request labels Jul 11, 2022
@cppforlife
Copy link
Contributor

hmm, this is a toughie. any thoughts on relationship of ~1.2 and prereleases. are they included?

@voor
Copy link
Author

voor commented Jul 18, 2022

Since the original use case is to avoid the prereleases of the version found in 1.3, I would say they should be included ideally.

@joaopapereira
Copy link
Member

Sorry was reading this issue and I think I did not follow 100%. Are you suggesting that the output of
vendir tools sort-semver -v "1.1.1 1.1.2 1.2.0 1.2.10-build.1 1.2.10 1.2.100-build.20 1.2.100 1.3.0-build.1 1.3.0-build.2" -c "~1.2" --prerelease --prerelease-identifier "build"
would be

1.2.0  
1.2.10-build.1  
1.2.10  
1.2.100-build.20  
1.2.100  

But if you did
vendir tools sort-semver -v "1.1.1 1.1.2 1.2.0 1.2.10-build.1 1.2.10 1.2.100-build.20 1.2.100 1.3.0-build.1 1.3.0-build.2" -c "~1.2"
the output would be

1.2.0
1.2.10
1.2.100

@voor
Copy link
Author

voor commented Aug 26, 2022

Yes, you got it.

@joaopapereira
Copy link
Member

Looks like an interesting addition.

For implementation sake, we will have to change the library https://github.com/k14s/semver in order to have support for the ~ operator

@joaopapereira joaopapereira added carvel-accepted This issue should be considered for future work and that the triage process has been completed priority/important-longterm Important over the long term, but may not be staffed and/or may need multiple releases to complete. and removed carvel-triage This issue has not yet been reviewed for validity labels Aug 26, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
carvel-accepted This issue should be considered for future work and that the triage process has been completed enhancement This issue is a feature request priority/important-longterm Important over the long term, but may not be staffed and/or may need multiple releases to complete.
Projects
Status: Unprioritized
Development

No branches or pull requests

3 participants