Packer plugin protocol version negotiation and automatic upgrade behavior

Plugin version resolution at init time

Packer 1.7+ uses a gRPC-based plugin protocol where the core negotiates a protocol major version at startup and rejects plugins advertising an incompatible major version. The packer init command resolves plugins declared in required_plugins blocks; when a version constraint uses a tilde (~> 1.2.3) or caret (^1.2.3), Packer selects the latest matching patch or minor release at init time and records the resolved versions in .packer.d/plugins.json.

Absence of automatic re-resolution

No documented mechanism causes Packer core to automatically upgrade already-installed plugins when a new core release ships. Operators must manually run packer init -upgrade or delete the lock file to trigger re-resolution. HashiCorp does not publish a formal compatibility matrix mapping Packer core versions to minimum or maximum plugin protocol versions, leaving users to infer compatibility from release notes. The packer plugins command lists installed plugins and their protocol versions but does not indicate whether a newer compatible plugin version exists.

Unresolved operational decision

This creates an open question for CI pipeline design: whether to pin exact plugin versions for reproducibility or allow floating ranges to receive bug fixes automatically, given that drift detection remains a manual process.

What criteria should determine whether a CI pipeline pins exact plugin versions versus allowing floating constraints? How can teams detect when a newer plugin version is available that remains compatible with the current Packer core without manual inspection? Is there a recommended pattern for automating packer init -upgrade in a way that avoids unexpected protocol mismatches?