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

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?