Packer Core and External Plugins: Plugin Version Resolution Behavior

Background

Packer 1.7+ loads external builders, provisioners, and post‑processors as separate processes using HashiCorp’s go‑plugin RPC protocol. The core and each plugin negotiate a protocol version during a gRPC handshake; a mismatch causes an immediate build failure.

Current Behavior

• Plugins are discovered only by binary name (packer-plugin-<type>_<name>) in ~/.packer.d/plugins or directories listed in PACKER_PLUGIN_PATH.
• When multiple versions of the same plugin exist, Packer selects the first matching binary in the search order without inspecting version metadata.
• No machine‑readable compatibility matrix maps Packer core releases to plugin protocol versions; the SDK version used by a plugin is not validated at runtime.

Open Questions

1. What deterministic rule, if any, governs plugin selection when several versions are present on the plugin path?
2. Is there a documented definition of “forward compatible” that plugin authors can rely on across minor Packer releases?
3. Can the handshake failure message be extended to indicate which side (core or plugin) advertises an unsupported protocol version?