Dependency versions

Plugins evolve, and if every developer runs whatever version happens to be latest, a fleet drifts into inconsistency: a command behaves one way on one machine and differently on another, and a bug that was fixed for some people still bites others. Pinning plugin versions solves this by making the version everyone runs an explicit, reviewed decision rather than an accident of when they last installed.

Why pin versions

Pinning gives you reproducibility and control. When a plugin version is fixed, a task that works today works the same way next week, and a support report can be tied to a known release. It also prevents a surprise upgrade from changing behavior mid-project, which is especially important for plugins used in automation where a silent change could break a pipeline. The tradeoff is that upgrades become deliberate, which is exactly the point.

Pinning a version

Specify the exact version when you install or configure a plugin, rather than tracking latest, so every machine resolves to the same release:

{
  "plugins": {
    "issue-linker": "2.3.1",
    "style-guard": "1.0.4"
  }
}

Commit this to a project or managed settings file so the whole team, and any automation, shares one set of versions. Treat a version change to this file as a normal code change: propose it, review it, and merge it.

Upgrading safely

Roll out plugin upgrades the way you roll out any dependency bump. Read the plugin’s changelog to understand what changed, test the new version against a real task before adopting it broadly, and upgrade in one place, the pinned configuration, so the fleet moves together. For plugins used in critical automation, stage the upgrade on a subset of jobs first. If a new version misbehaves, pinning makes rollback trivial: revert the version number and the fleet returns to the known-good release.