You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Build-PSModule compiles #Requires -Modules statements into the manifest RequiredModules, but there is no control over how tightly each dependency's version is constrained. Exact pins cause staleness and breakage (e.g. the 2026-07-05 Pester 5.7.1 vs 5.8.0 CI breakage); no constraint causes non-reproducible builds and supply-chain exposure. Module authors need a policy knob matched to their risk appetite.
Add a configurable version-lock policy that Build-PSModule applies when writing RequiredModules, with a per-module default (in PSModule.yml) and a per-dependency override. For a resolved dependency 2.4.7 / GUID G:
Level
Intent
Compiled expression
Latest
always newest
ModuleVersion floor only
LockMajor
minor + patch, block next major
ModuleVersion='2.4.7' + MaximumVersion='2.*'
LockMinor
patch only
ModuleVersion='2.4.7' + MaximumVersion='2.4.*'
LockPatch
exact version
RequiredVersion='2.4.7'
LockGUID
exact version + identity
RequiredVersion='2.4.7' + GUID='G'
Acceptance criteria
A PSModule.yml setting sets the default lock level for a module.
Per-dependency overrides are supported.
Build-PSModule resolves the concrete installed version at build time and writes the corresponding constraint into RequiredModules.
The recommended default is documented (proposed: LockMinor for published dependencies; LockPatch when vendoring).
Behaviour is covered by the framework test harness.
Notes
The manifest primitives already exist (ModuleVersion / RequiredVersion / MaximumVersion / GUID); this issue is the policy layer that chooses among them.
Balances the two risks called out in the epic: supply-chain (too loose) vs. staleness (too tight).
The default must not be an exact pin by default — exact RequiredVersion on shared test dependencies is what broke CI on 2026-07-05.
Context
Build-PSModulecompiles#Requires -Modulesstatements into the manifestRequiredModules, but there is no control over how tightly each dependency's version is constrained. Exact pins cause staleness and breakage (e.g. the 2026-07-05 Pester5.7.1vs5.8.0CI breakage); no constraint causes non-reproducible builds and supply-chain exposure. Module authors need a policy knob matched to their risk appetite.Part of #356.
Request
Add a configurable version-lock policy that
Build-PSModuleapplies when writingRequiredModules, with a per-module default (inPSModule.yml) and a per-dependency override. For a resolved dependency2.4.7/ GUIDG:LatestModuleVersionfloor onlyLockMajorModuleVersion='2.4.7'+MaximumVersion='2.*'LockMinorModuleVersion='2.4.7'+MaximumVersion='2.4.*'LockPatchRequiredVersion='2.4.7'LockGUIDRequiredVersion='2.4.7'+GUID='G'Acceptance criteria
PSModule.ymlsetting sets the default lock level for a module.Build-PSModuleresolves the concrete installed version at build time and writes the corresponding constraint intoRequiredModules.LockMinorfor published dependencies;LockPatchwhen vendoring).LockPatch/LockGUID.Notes
ModuleVersion/RequiredVersion/MaximumVersion/GUID); this issue is the policy layer that chooses among them.RequiredVersionon shared test dependencies is what broke CI on 2026-07-05.