Update-PSResource: Include local-copy prerelease string when deciding update applicability

[sean-r-williams]

PR Summary

This PR updates Microsoft.PowerShell.PSResourceGet.Cmdlets.UpdatePSResource to consider a locally-installed resource's prerelease string when comparing against the repository's available versions.

Fixes #1953.

PR Context

Currently, Update-PSResource only considers the locally-installed resource's version component from the PSResourceInfo.Version field, of type System.Version. This struct doesn't include prerelease strings - PSResourceInfo.Prerelease contains those.

This means that if I have:

• A locally-installed resource, with version 1.0.1-pre
• A remote repository resource, with version 1.0.1
• The same version number between the two (sans prerelease - i.e. the module's prerelease "graduated")
  ...then Update-PSResource will mistakenly mark the locally-installed version as "up to date".

JiraPS, which recently released 2.15.0 (having previously released 2.15.0-alpha1 in 2024), falls into this bucket.

This behavior needs a test. Publishing a test module to Gallery with a prerelease, then normal-release version (i.e. 1.0.1-pre and 1.0.1) would be enough to test this behavior.

If someone from the Gallery team can publish a test module, I'm happy to contribute a test to test\UpdatePSResourceTests\UpdatePSResourceV2.Tests.ps1 as part of this PR.

PR Checklist

• PR has a meaningful title
  • Use the present tense and imperative mood when describing your changes
• Summarized changes
• Make sure all .h, .cpp, .cs, .ps1 and .psm1 files have the correct copyright header
• This PR is ready to merge and is not Work in Progress.
  • If the PR is work in progress, please add the prefix WIP: or [ WIP ] to the beginning of the title (the WIP bot will keep its status check at Pending while the prefix is present) and remove the prefix when the PR is ready.
• Breaking changes
  • None
  • OR
  • Documentation needed
    • Issue filed:
• User-facing changes
  • Not Applicable
  • OR
  • Documentation needed
    • Issue filed:
• Testing - New and feature
  • N/A or can only be tested interactively
  • OR
  • Make sure you've added a new test if existing tests do not effectively test the code changed
• Tooling
  • I have considered the user experience from a tooling perspective and don't believe tooling will be impacted.
  • OR
  • I have considered the user experience from a tooling perspective and enumerated concerns in the summary.

[kilasuit]

@sean-r-williams re this

This behavior needs a test. Publishing a test module to Gallery with a prerelease, then normal-release version (i.e. 1.0.1-pre and 1.0.1) would be enough to test this behavior.

If someone from the Gallery team can publish a test module, I'm happy to contribute a test to test\UpdatePSResourceTests\UpdatePSResourceV2.Tests.ps1 as part of this PR.

I'd just write a test against the available PSResourceGet versions as opposed to creating other test modules for this as PSResourceGet does have pre-release and non-prerelease versions as I can't see the team delisting a version unless really needed

[anamnavi]

thanks for this bugfix @sean-r-williams and my apologies for the delay in getting to it! I've linked the upstream branch/PR here where I'm running tests, but you'll notice I've published the module version as you mentioned and added a test. You'll want to rebase your branch and add that test, thanks!

[sean-r-williams]

@anamnavi Apologies, I changed teams at the start of April and my day-to-day interaction with PowerShell has decreased while re-ramping.

I think 3758ffb captures the test I was going to write, so I'm not sure if there's any action I can take here. Let me know if you need me to rebase or anything.

[anamnavi]

LGTM. Thanks for the contribution @sean-r-williams !