Support NuGet version range syntax for the Version input

[MariusStorhaug]

The action runs PowerShell scripts that depend on the GitHub PowerShell module, and workflow authors choose which version of that module is installed through the Version input. Today the Version input accepts only a single exact version — its description states the value "must be an exact version."

Request

Desired capability

The Version input should accept a NuGet version range in addition to a plain exact version — the same syntax that PSResourceGet already uses. Workflow authors could then express an acceptable window instead of pinning a single build, for example:

Intent	Value
Exact version (unchanged)	1.2.3
Exact match	[1.2.3]
Minimum, inclusive	[1.2.0, ]
Maximum, exclusive	(, 2.0.0)
Bounded window	[1.2.0, 2.0.0)

This matters because the current model forces a choice between hardcoding one exact version — which never picks up compatible fixes — and omitting Version entirely, which always installs the latest with no floor or ceiling. A range lets a workflow accept compatible updates automatically while still guarding against an unwanted major bump. It also aligns the action with the direction of PSResourceGet, whose cmdlets already resolve versions using this notation.

Acceptance criteria

• The Version input accepts NuGet version range notation as well as a plain exact version.
• Existing workflows that pass an exact version (for example 1.2.3) install exactly that version — no behavior change.
• When a range is supplied, a module version that satisfies the range is installed. (PSResourceGet resolves a range to the lowest satisfying version.)
• A module version that already satisfies the requested version or range is not reinstalled unnecessarily.
• Prerelease handling continues to work alongside a version range.
• The input documentation lists the supported notations with examples.

---

Technical decisions

The installer already speaks this syntax. src/init.ps1 already installs the module with Install-PSResource, whose -Version parameter accepts an exact version or a NuGet version range. The work is to expose and document that capability and to correct the already-installed check — not to swap the installer.

Pass the value through; do not build a custom parser. The Version input is forwarded verbatim to Install-PSResource -Version. PSResourceGet validates the syntax and resolves the range, so the action does not implement its own range parsing or validation.

A bare version stays exact — this is not a breaking change. Per the -Version documentation, PSResourceGet treats a bare version such as 1.2.3 as the required (exact) version, not "minimum inclusive". Existing consumers keep identical behavior, so the change is purely additive. A minimum-inclusive range must be written [1.2.3, ].

Fix the already-installed check. The current logic in src/init.ps1 filters installed resources with Get-InstalledPSResource -Name $Name | Where-Object Version -EQ $Version. String equality never matches a range such as [1.2.0, 2.0.0), so a range would force a reinstall on every run. Replace it with Get-InstalledPSResource -Name $Name -Version $Version: Get-InstalledPSResource accepts the same NuGet range syntax and returns the installed versions that satisfy the range, delegating satisfaction to PSResourceGet and keeping detection consistent with installation.

Prerelease remains a separate switch. Install-PSResource keeps -Prerelease as a distinct switch rather than encoding prerelease acceptance in the version string, so the existing Prerelease boolean input is retained and passed through. It composes with the range: a prerelease is only considered when Prerelease is true, matching PSResourceGet semantics where a prerelease sorts below its stable counterpart within a range.

Scope. Only the Version input semantics and description and the already-installed check change. No new inputs are added, and Prerelease behavior is unchanged.

---

Implementation plan

Core changes

• Update the Version input description in action.yml from "must be an exact version" to "an exact version or a NuGet version range".
• In src/init.ps1, replace the Where-Object Version -EQ $Version already-installed filter with Get-InstalledPSResource -Name $Name -Version $Version so installed-version detection honors ranges.
• Confirm the Version value is forwarded unchanged to Install-PSResource -Version and that the $moduleStatus "Version" display reads sensibly when a range is supplied.
• Verify the Prerelease input still composes correctly with a version range.

Documentation

• Update the Version row in the README inputs table and add examples for exact (1.2.3), exact-match ([1.2.3]), minimum-inclusive ([1.2.0, ]), maximum-exclusive ((, 2.0.0)), and bounded ([1.2.0, 2.0.0)) notations.
• Add a note that a bare version is treated as an exact/required version rather than a minimum, linking to the NuGet version range reference.

Tests

• Add version-range coverage to the action test workflow (.github/workflows/TestWorkflow.yml) exercising exact version, minimum-inclusive range, bounded range, and no Version (latest).
• Cover the prerelease + range combination in .github/workflows/Action-Test-Prerelease.yml.
• Verify the already-installed short-circuit does not reinstall when an installed version already satisfies the requested range.

[MariusStorhaug]

Implemented in #98 using a test-first flow:

• Added version-input tests to TestWorkflow.yml (exact, bounded range, minimum range, and an already-installed reuse case).
• The already-installed test failed first on the unfixed code (the exact-string check never matched a range, so the action reinstalled the range floor 0.38.0 alongside the pre-installed 0.40.0 — two versions), then passed after switching the check to Get-InstalledPSResource -Name $Name -Version $Version.

Note discovered while testing: PSResourceGet resolves a range to the lowest satisfying version (a bounded [0.38.0, 0.40.0) installs 0.38.0), not the newest. The acceptance criteria wording was corrected accordingly. The retry loop around Install-PSResource is preserved.