Why can upgrading Jenkins plugins be risky, and what does the LTS release line have to do with it?

## Two release lines that do not move together Jenkins core ships two ways. **Weekly** releases (2.x) come out most weeks and carry new features immediately. The **LTS** line picks one weekly as a baseline about every twelve weeks and then publishes patch releases against it — versions of the form 2.479.1, 2.479.2, where 2.479 is the chosen weekly and the last digit is the patch level. LTS carries backported fixes only, so it is the line almost every production controller should sit on. Plugins have no such train. Each plugin is released by its own maintainer whenever they like, with no coordination across the ecosystem and no guarantee that two plugins you use were ever tested together at the versions you are running. ## What actually couples plugins to core Every plugin release declares `Jenkins-Version` in its manifest: the oldest core it will run on. Maintainers periodically raise that baseline, and the project's guidance encourages targeting a reasonably recent LTS. The moment a maintainer bumps it past your core, the Plugin Manager stops offering you that plugin's newest version — it shows a compatibility warning instead. You are pinned to an older release, and if a security advisory lands on that older release, the only fix is to move core first. Core upgrades then have their own prerequisites. The project has moved its minimum Java baseline forward more than once (from 8, to 11, to 17, with newer LTS support added since), so a chain that started as "upgrade one plugin" can end as "upgrade the JVM and the base image". That cascade is the honest answer to why teams postpone Jenkins upgrades until they are painful. ## Why one plugin upgrade moves plugins you did not touch A controller loads **exactly one** copy of each plugin. There is no per-consumer version resolution as in a language package manager: if plugin A requires Credentials at version X or newer, upgrading A upgrades Credentials for every other plugin in the JVM at the same time. A dependency graph across sixty or a hundred plugins therefore behaves like a single lockstep application — one upgrade ripples, and the blast radius is the whole controller rather than one job. ## Version numbers tell you almost nothing Many plugins publish versions derived from the build rather than from semantic versioning — a large number followed by a commit-derived suffix. Others use plain sequential numbers. Either way you cannot read "patch" or "breaking" out of the number the way you can with a strict semver library. The changelog on the plugin's page is the only real signal, which is why blanket "update all" clicks are how controllers break. ## The failure mode, and why it stings Upgrades run live against a stateful controller. A bad plugin version can fail to load, and jobs whose configuration references its classes can fail to deserialize; in the worst case the controller does not come back up at all. Recovery is then **offline**, because the UI you would fix it in is the thing that is down: ```bash # On the controller host, with Jenkins stopped cd "$JENKINS_HOME/plugins" mv bad-plugin.jpi.bak bad-plugin.jpi # restore the pre-upgrade file rm -rf bad-plugin # drop the exploded directory ``` Jenkins keeps the previous file as `<shortname>.jpi.bak` on upgrade, which is also what the Installed tab's "Downgrade" button uses when the UI is still reachable. ## What good practice looks like - **Sit on LTS** and upgrade core on its cadence rather than drifting years behind. Distance from the current baseline is what makes an upgrade a project instead of a maintenance task. - **Batch plugin upgrades on a staging controller** restored from a copy of `JENKINS_HOME`, then promote the same set. Testing against real job configs is the only test that means anything, because the risk lives in your job definitions as much as in the plugins. - **Read security advisories** and prioritise by exposure rather than by what the Updates tab lists first. - **Keep the plugin list small.** Every extra plugin is another maintainer who gets a vote on when you may upgrade core. - **Pin versions declaratively** so an upgrade arrives as a reviewable diff and a rollback is redeploying the previous build, instead of a click nobody recorded. ## The interview point The candidate who says "upgrade regularly, it is fine" has not run an old controller. The one who says "never upgrade" has not read an advisory. The good answer describes the coupling — plugin to plugin, plugin to core, core to JVM — and then describes a cadence and a rehearsal step that make the coupling survivable.