Unexpected plugin version selection after packer init -upgrade with ranged constraints

Question

Teams using Packer want to ensure that image builds remain reproducible after a plugin upgrade while still being able to roll back to a known‑good state if the upgrade introduces issues. The documented recovery path relies on adjusting the version constraint in the required_plugins block and re‑running packer init, which installs plugins that satisfy the constraint side‑by‑side in the plugin directory. However, it is unclear whether Packer always picks the highest satisfying version when multiple versions coexist, and whether using a permissive range such as ~>1 leads to silent behavior changes during an automatic upgrade.

Determine the best practice for version pinning versus ranged constraints, and verify how Packer resolves conflicts between installed plugin versions.

Does Packer select the highest version that satisfies the constraint when more than one version of a plugin is present on disk?
When a range like ~>1 is used, does packer init -upgrade automatically install a newer minor version that could alter build behavior without an explicit version change?
Should teams exact‑pin each plugin version to guarantee reproducibility, and how does that affect the rollback workflow?

Tasadduq Burney · Answer

Answer
Packer always selects the highest version that satisfies the constraint when multiple versions of a plugin are present on disk.
Confirmed facts

When more than one version of a plugin exists in the plugin directory, Packer picks the highest satisfying version.
A permissive constraint such as ~>1 allows packer init -upgrade to install the newest minor/patch release within the same major version, which can change build behavior without an explicit version change in the configuration.
Exact‑pinning each plugin version (e.g., version = "1.2.3") guarantees reproducible builds; rolling back is done by changing the constraint back to the prior pinned version and running packer init again, which will reinstall that version if it is still available locally or fetch it from the registry.

Steps to verify or apply the best practice

Define your required_plugins block with an exact pin for each plugin you need to lock.
Run packer init (or packer init -upgrade if you intentionally want to allow upgrades) to install the pinned version.
To roll back, edit the constraint to the previous known‑good version and run packer init again; Packer will reinstall that version.
If you must use a ranged constraint, test upgrades in an isolated environment: keep two versions side‑by‑side, run packer init -upgrade, and check the debug output or packer plugins installed to confirm which version was selected.

Unexpected plugin version selection after packer init -upgrade with ranged constraints

1 answer

Answer

Confirmed facts

Steps to verify or apply the best practice

Your perspective belongs here.

0 question comments