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

Filter prereleases #159

Open
karl-dpg opened this issue Feb 4, 2021 · 8 comments
Open

Filter prereleases #159

karl-dpg opened this issue Feb 4, 2021 · 8 comments
Labels

Comments

@karl-dpg
Copy link

karl-dpg commented Feb 4, 2021

Hi. Is there a way how to filter prereleases? Assuming the below versions (ordered):

1.0.0-beta.2
1.0.0-beta.1
1.0.0-alpha.2
1.0.0-alpha.1

Is it possible to select only the alpha versions, and ignore the betas?

@mattfarina
Copy link
Member

It is possible. Here's an example... https://play.golang.org/p/Ix-OuFIQQoT

If you're just looking for the version range... >= 1.0.0-beta

@hpdobrica
Copy link

hpdobrica commented May 19, 2022

This works for me if I look for a fixed version like >= 1.0.0-rc, but it doesn't if I try a constraint like >= 0.0.0-rc.

What i'm trying to achieve is get the latest release candidate version, regardless of what version it is. When I try the >= 0.0.0-rc, it successfully tests against all -rc releases, but also against all -beta releases as well. As the matter of fact, if i use 0.0.0, it seems like it doesn't matter what i put after the dash, as long as i put something (which enables looking at pre-releases)

Is there any way to overcome this and get a constraint which tests positive only for -rc versions?

Edit: i now understand why it behaves like this, it makes sense, but would still like to know if there is a way to find solution to the scenario above

@mattfarina
Copy link
Member

You can use 2 different constraints together. You can see some example at https://github.com/Masterminds/semver#caret-range-comparisons-major

@aalvarezaph
Copy link

@hpdobrica Did you find a solution for your scenario? I was actually considering the same scenario, a range that would deploy any -rc version but that wouldn't include other prereleases.

So given:

1.0.0-rc.1
1.1.0-beta.1

Then 1.0.0-rc.1 should be chosen.

But at the same time if 1.1.0-rc.1 is released, it should be chosen instead without having to modify the range expression.

Took a look at caret ranges suggested by @mattfarina but don't see how I could use them to handle the scenario with a fixed range expression

@mattfarina
Copy link
Member

@aalvarezaph are you using the semver package directly or trying to come up with an expression to use with an application that uses semver?

@aalvarezaph
Copy link

Second option, I am actually using the expression on a HelmRelease CR from Flux. If I'm not wrong this should be the function handling the logic.

At the same time, I have now opted for not using RC's so don't want to waste your time on this @mattfarina (but if you have a direct answer it might be helpful for future readers of course)

@baby-gnu
Copy link

baby-gnu commented May 4, 2023

We encounter the same kind of issue for helm dependencies:

  • on alpha branch, we want the latest -alpha prerelease
  • on beta branch, we want the latest -beta prerelease

we have the following tags:

  • 1.2.0
  • 1.2.1-alpha.1
  • 1.2.1-alpha.2
  • 1.2.1-beta.1

The only solution we have for now is:

  • use <1.2.1-beta.0 on the alpha branch
  • use <2.0.0-0 on the beta branch

But this requires to update the dependency field on each cycle or even worse since the dependency versionning is done using semantic-release.

@torarnv
Copy link

torarnv commented Mar 17, 2024

It is possible. Here's an example... https://play.golang.org/p/Ix-OuFIQQoT

If you're just looking for the version range... >= 1.0.0-beta

How would you exclude the released version, if you explicitly want to test a beta?

https://go.dev/play/p/xnnm92lpzIW

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

No branches or pull requests

6 participants