Question
Does Pulumi v4 reject loose semantic version ranges for provider plugins, causing upgrade failures?
Sky River
0 reputation · 28 Mar 2021, 10:35 UTC
124.8K views1
Loading…
0 reputation · 28 Mar 2021, 10:35 UTC
When upgrading a Pulumi project from the v3.x CLI to v4.x, the goal is to confirm whether the CLI will accept provider plugin version specifications that use loose semantic version ranges (for example, aws: ^4.0.0) or if it now requires an exact version match.
In Pulumi v3, the plugin resolver allowed such ranges and would download the latest compatible version, whereas v4 introduced stricter compatibility checks that may reject a range if no published version exactly satisfies the constraint.
Uncertainty remains about the exact behavior: does v4 treat a caret range as a minimum version requirement, does it fail to download a plugin when the range maps to no available version, and can the behavior be overridden through project configuration or CLI flags?
35775 reputation · 28 Mar 2021, 12:17 UTC
Pulumi v4 does not appear to reject all loose semantic version ranges outright. A provider constraint such as aws: ^4.0.0 is not automatically invalid. The more likely failure mode is that v4 applies stricter plugin compatibility checks or resolves against a different plugin index, causing a range that worked in v3 to fail when no published plugin binary satisfies the constraint.
Confirmed: Pulumi v3 accepted semver ranges in Pulumi.yaml and resolved them to the latest compatible plugin. Major CLI upgrades can change plugin resolution without changing the YAML schema.
Likely: v4 is not enforcing a blanket exact-match rule. Instead, the resolver may treat the range differently, query a different repository, or reject the download when the local plugin cache contains a stale v3 binary that does not satisfy v4 compatibility.
pulumipulumi plugin ls and check the provider version actually present.pulumi preview and capture the exact error text. Download-time errors such as "no plugin found" indicate range resolution; plan-time errors indicate provider or SDK mismatch.Pulumi.yaml (for example, aws: 4.5.0) and re-run pulumi preview. If the error disappears, the range is the problem.~/.pulumi/plugins) and retry with the original range to rule out stale v3 artifacts.pulumi new to see the default provider version syntax, and consult the official v4 migration guide for documented plugin resolution changes.If the error names a specific plugin repository or index URL, the next step is verifying repository access or configuration rather than editing version constraints. If it only reports a version mismatch, pinning is the fastest resolution.
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.