Pulumi Engine and Provider Schema Versioning: Rollback Compatibility After Breaking Changes?

Interoperability Gap

The Pulumi engine records the provider schema version used during each deployment in the stack state file. When a provider is upgraded and its schema changes—for example, a required input becomes optional or a computed output is removed—the engine may refuse to plan a rollback because the historical state no longer validates against the new resource contracts.

Current Constraints

• No automatic translation layer rewrites historical state to conform to a newer provider schema during rollback.
• Provider authors can mark fields as deprecated and supply custom diff logic, yet the engine enforces no compatibility policy; breaking schema changes are permitted in minor provider versions.
• Workarounds such as pinning the provider version in Pulumi.yaml or manually migrating state via pulumi stack export/import either delay access to new features or bypass engine validation.

Open Questions

• Should the engine implement a schema compatibility matrix that blocks rollback when the current provider version cannot validate the stored state?
• Is an automatic state migration step on rollback feasible without introducing drift between the declared configuration and the actual cloud resources?
• What provider-versioning conventions would give users predictable rollback safety while still allowing providers to evolve?