Inexact operators for prerelease version constraints

[Jellayy]

OpenTofu Version

❯ tofu version
OpenTofu v1.7.1
on darwin_arm64

Use Cases

I help to maintain modules that deploy across a large number of workspaces and want to integrate a tiered deployment strategy. That involves releasing alpha, beta, and release candidate releases of these modules alongside mainline releases.

I have a groups of workspaces that I'd like to pull in these different prerelease channels. Ideally, that would be accomplished by setting these workspaces to take in the module with something similar to >= 1.0.0-beta.1 or ~> 1.0-rc.1. However, prerelease versions can currently only be selected by an exact version constraint.

Attempted Solutions

On a module that has the versions: 1.0.1, 1.1.0-beta.1, 1.1.0-beta.2, 1.1.0-beta.3, 1.1.0-rc.1 available, setting the version constraint to an inexact operator such as >= 1.1.0-beta.1 results in the following:

There is no available version of module "..." (main.tf:1) which matches the given version constraint. The newest available version is 1.0.1.

However, setting the version constraint to an exact operator such as 1.1.0-beta.1 pulls down the module version properly.

I also attempted pulling down the latest prerelease module version separately and inserting it into the version constraint as a variable, which is also not supported. However, that's definitely out of scope for this issue.

Proposal

Hashicorp developers previously shot down a request for this in Terraform citing that "pre-release tags do not necessarily follow the normal semver order semantics" despite the fact that semver does have defined specs for prereleases. Additionally that "one usually does not desire any pre-releases to be included in a range of semantic versions" when there are a number of reasons for wanting to pull in the latest release or release range in a certain release channel.

My proposal is that OpenTofu support the full range of semver in version constraint strings on inexact operators i addition to the exact operators that are currently supported.

References

No response

[janosdebugs]

Hello and thank you for this issue! The core team regularly reviews new issues and discusses them, but this can take a little time. Please bear with us while we get to your issue. If you're interested, the contribution guide has a section about the decision-making process.

[cube2222]

Hey! Thanks for submitting the issue.

Could you expand on how those matches would work? Basically, you definitely don't want something like >= 1.6.0 to match 1.7.0-alpha1. Linking a relevant document that details this would be totally fine.

I suppose one approach would be to only match prereleases if the constraint contains a prerelease tag. An alternative would be to have a separate field which would indicate if prereleases should be ignored or not.

[Jellayy]

Yeah, I think ideally it would be best to have prerelease versions only be taken in when you specify.

Existing constraint strings such as >= 1.6.0, ~> 1.5.0 would be unaffected

But once you add a prerelease tag (>=1.6.0-beta.1), the hierarchy starts getting evaluated.

semver has an example hierarchy laid out:

1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-alpha.beta < 1.0.0-beta < 1.0.0-beta.2 < 1.0.0-beta.11 < 1.0.0-rc.1 < 1.0.0

How I've found this actually works on the their end is they sort alphabetically. So while alpha -> beta -> rc works, the spec will technically allow for any tags you add.

For example:

• >= 1.0.0-rc.1 would take in 1.0.0-rc.1 then 1.0.0
• >= 1.0.0-beta.2 would take in 1.0.0-beta.2, 1.0.0-beta11, 1.0.0-rc.1, then 1.0.0

You could also possibly scope to one particular release channel with the ~> operator, since it allows only the rightmost version component to increment:

• ~> 1.0.0-beta.1 would take in all 1.0.X-beta.X releases
• ~> 1.0-rc.1 would take in all 1.X.X-rc.X releases
• ~> 1-rc.1 could take in every release canidate?

Definitely open to see input from others on how this would work + any edge cases that might need this to be handled differently.