Context and request
Observed behavior: BumpMajor(), BumpMinor(), and BumpPatch() change only the numeric components. Any prerelease label and build metadata already on the object survive the bump.
Import-Module PSSemVer
$v = [PSSemVer]'1.2.3-alpha.1'
$v.BumpMajor()
$v.ToString() # 2.0.0-alpha.1
$v = [PSSemVer]'1.2.3+abc'
$v.BumpMinor()
$v.ToString() # 1.3.0+abc
Expected behavior: a decision, documented on the class, about what a bump means for the labels. The common convention in SemVer tooling is that bumping a numeric component produces a clean release of that component — 1.2.3-alpha.1 bumped major becomes 2.0.0 — because the prerelease and the build metadata described the old version, not the new one.
Reproduction: the snippet above.
Environment: PSSemVer 1.1.9, PowerShell 7.6.4. Not platform specific — the behaviour is in src/classes/public/PSSemVer.ps1.
Regression: no. The Bump* methods have never touched the labels.
Workaround: clear the labels explicitly after bumping.
$v.BumpPatch()
$v.SetPrerelease('')
$v.SetBuildMetadata('')
Acceptance criteria:
- The behaviour of each
Bump* method with respect to Prerelease and BuildMetadata is decided, documented in the class help and README, and covered by tests.
- Whatever is decided,
1.2.3-alpha.1 bumped patch does not silently produce a version that release automation would publish as a prerelease.
Technical decisions
This matters beyond the module itself. PSModule/Resolve-PSModuleVersion resolves the latest published version, calls BumpMajor/BumpMinor/BumpPatch on it, and only then assigns Prerelease — and only when the run is producing a prerelease. If the resolved latest version ever carries a prerelease label, a stable release run inherits it and publishes a prerelease-looking version. isLatest on GitHub normally excludes prereleases, which is why this has not surfaced, but the class contract should not depend on a caller's filtering.
The decision to make: whether Bump* clears Prerelease and BuildMetadata (specification-aligned, breaking for anyone relying on today's behaviour), or whether the labels are preserved and the documentation says so explicitly so callers know they must clear them. Once decided, Resolve-PSModuleVersion should be reviewed against the documented contract.
Implementation plan
Record the decision in this issue, add tests that pin the chosen behaviour for all three Bump* methods with a prerelease and with build metadata present, implement it, update the class help and README, then review the Resolve-PSModuleVersion call site against the documented contract.
Context and request
Observed behavior:
BumpMajor(),BumpMinor(), andBumpPatch()change only the numeric components. Any prerelease label and build metadata already on the object survive the bump.Expected behavior: a decision, documented on the class, about what a bump means for the labels. The common convention in SemVer tooling is that bumping a numeric component produces a clean release of that component —
1.2.3-alpha.1bumped major becomes2.0.0— because the prerelease and the build metadata described the old version, not the new one.Reproduction: the snippet above.
Environment: PSSemVer 1.1.9, PowerShell 7.6.4. Not platform specific — the behaviour is in
src/classes/public/PSSemVer.ps1.Regression: no. The
Bump*methods have never touched the labels.Workaround: clear the labels explicitly after bumping.
Acceptance criteria:
Bump*method with respect toPrereleaseandBuildMetadatais decided, documented in the class help and README, and covered by tests.1.2.3-alpha.1bumped patch does not silently produce a version that release automation would publish as a prerelease.Technical decisions
This matters beyond the module itself.
PSModule/Resolve-PSModuleVersionresolves the latest published version, callsBumpMajor/BumpMinor/BumpPatchon it, and only then assignsPrerelease— and only when the run is producing a prerelease. If the resolved latest version ever carries a prerelease label, a stable release run inherits it and publishes a prerelease-looking version.isLateston GitHub normally excludes prereleases, which is why this has not surfaced, but the class contract should not depend on a caller's filtering.The decision to make: whether
Bump*clearsPrereleaseandBuildMetadata(specification-aligned, breaking for anyone relying on today's behaviour), or whether the labels are preserved and the documentation says so explicitly so callers know they must clear them. Once decided,Resolve-PSModuleVersionshould be reviewed against the documented contract.Implementation plan
Record the decision in this issue, add tests that pin the chosen behaviour for all three
Bump*methods with a prerelease and with build metadata present, implement it, update the class help and README, then review theResolve-PSModuleVersioncall site against the documented contract.