Fix version resolution ignoring the bump label on pull requests #378

Modules built with the Process-PSModule workflow signal
the intended release size by applying a version-bump label (major, minor, or patch) to a pull
request. While the pull request is open, the pipeline resolves and reports the version the change would
produce, so the author can confirm the next version before merging.

Request

What happens

On a pull request the resolved/previewed version always reflects a patch increment, regardless of
which bump label is applied. For a repository whose latest release is v0.4.1, a pull request labelled
minor previews v0.4.2-<branch> instead of v0.5.0-<branch>. The bump label appears to be ignored
until the pull request is merged into the default branch, so the author cannot see the version the change
will actually create.

What is expected

The previewed version reflects the applied bump label: a minor pull request previews the next minor
version, a major pull request previews the next major version, and so on. Whether the run publishes
anything is a separate concern and should be controlled independently (by the prerelease label and the
merge event), not conflated with which version is shown.

Reproduction steps

1. Use a module repository whose latest release is, for example, v0.4.1.
2. Open a pull request and apply the minor label (and no prerelease label).
3. Open the run's Plan → Resolve-Version step.
4. Observe the resolved version is v0.4.2-<branch>NNN (a patch), not v0.5.0-<branch>NNN.

Environment

• Process-PSModule: v6.1.1 (also reproduces on the current default branch)
• Event: pull_request

Regression

Not a recent regression. The bump label has only ever been evaluated on publishing events, so
non-publishing pull requests have always previewed a patch version.

Workaround

Also apply a prerelease label: that switches the run to a prerelease-publishing event, which causes the
bump label to be evaluated. It has the side effect of actually publishing a prerelease, so it is not a
true preview.

Acceptance criteria

• On a pull request, the previewed version reflects the applied major/minor/patch label.
• With no bump label, the preview still falls back to a patch version.
• The prerelease label controls only whether a prerelease is published — not which version is shown.
• Released version numbers on merge to the default branch are unchanged.

Technical decisions

Root cause: The version-bump label evaluation lives in
PSModule/Resolve-PSModuleVersion, invoked by the
Resolve-Version step of
Plan.yml. In
Resolve-ReleaseDecision the major/minor/patch evaluation was nested inside an
if ($shouldPublish) { ... } block. On a pull_request event,
Get-PSModuleSettings sets
Settings.Publish.Module.ReleaseType = 'None' (a release is only cut on merge to the default branch, or a
prerelease when the prerelease label is present), so ShouldPublish is $false, the label block is
skipped, and the decision falls back to a patch bump.

Fix approach: Always evaluate the bump labels in Resolve-ReleaseDecision, independent of
ShouldPublish. ReleaseType (and the prerelease label that drives it) then controls only whether and
how the run publishes — never the version increment. The no-bump-label fallback continues to default to
patch and to not publish an unlabelled change.

Fix location: The change belongs in Resolve-PSModuleVersion (proposed in
PSModule/Resolve-PSModuleVersion#9).
Process-PSModule consumes it by bumping the pinned Resolve-PSModuleVersion reference in Plan.yml once
released.

Backward compatibility: All existing Resolve-PSModuleVersion decision, version and end-to-end test
cases are unchanged; the only behavioural difference is for label combinations that were previously never
evaluated (for example minor on a non-publishing event). Merge-to-default-branch releases are
unaffected.

Verified: With the fix wired in, a minor-labelled pull request against v0.4.1 previews
v0.5.0-<branch>001 with ShouldPublish = False (was v0.4.2-<branch>001 before).

Related: #373 concerns a separate Resolve-Version gap on schedule/workflow_dispatch events. This
issue is specifically about bump labels being ignored on pull_request events.

Implementation plan

Resolve-PSModuleVersion

• Move the major/minor/patch label evaluation out of the if ($shouldPublish) gate in
  Resolve-ReleaseDecision so it always runs (#9)
• Keep the no-bump-label fallback (default patch, do not publish an unlabelled change)
• Add unit tests for None + minor and None + major previews
• Release a new Resolve-PSModuleVersion version

Process-PSModule

• Bump the pinned Resolve-PSModuleVersion reference in .github/workflows/Plan.yml to the released version
• Confirm on a labelled pull request that the previewed version reflects the bump label