Filter prereleases

[karl-dpg]

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]

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]

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]

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

[aalvarezaph]

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

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

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]

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]

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