Each plugin's META-INF/MANIFEST.MF names the oldest core it runs on (Jenkins-Version, 2.541.1 for GitHub 29 Branch Source 1983.vfa_27ed961853) and its Plugin-Dependencies, each a minimum version with no upper bound, unlike an npm 2,036 range such as ^1.45.0: GitHub Branch Source asks for github 1.45.0 and runs on the installed 1.47.0. Optional dependencies add features only when the other plugin is present; implied ones are added silently for code split out of core into detached plugins such as Mailer and JUnit 48,319 . Versions like 1983.vfa_27ed961853 are a commit count plus an abbreviated Git 1,932 hash.
Jenkins 1 8,793 .x could pin a plugin with a .jpi.pinned file; Jenkins 2.0 removed that. Today you pin by writing exact versions in a plugins file (plugins.txt) and never clicking Update on a production controller. Because dependencies only have minimums, a pin that is too old fails loudly:
printf 'git:5.10.1\ngit-client:6.1.0\n' > conflict.txt
docker run --rm -v "$PWD":/w jenkins/jenkins:2.568.3-lts-jdk21 \
jenkins-plugin-cli -f /w/conflict.txt -d /tmp/p... Plugin prerequisite not met: Plugin git:5.10.1 depends on git-client:6.5.0, but there is an older version defined on the top level - git-client:6.1.0
The tool refuses an inconsistent set; on the way it also printed the update center's security warning for Git Client (SECURITY-3723, an OS command injection fixed in June 2026). Treat pins as a snapshot you refresh deliberately, not a way to stay on old plugins.