An LTS baseline is picked from a weekly release every 12 weeks and patched twice at four-week intervals: 2.555.1 on 15 April 2026, 2.555.2 and 2.555.3, then 2.568.1 on 8 July and 2.568.3 on 2 September, with the next baseline due at the end of September. Before each move, read the upgrade guide for every baseline you cross (jenkins.io/doc/upgrade-guide (https://www.jenkins.io/doc/upgrade-guide/ 8,793 )): 2.555.1 made Java 21 the minimum, and 2.568.1 dropped the Windows Server 2019 controller images.
In a container an upgrade is a new image on the same volume, the step Persisting JENKINS_HOME practiced. To try it end to end, a throwaway controller started on the previous line, 2.555.3, with the setup wizard skipped; a freestyle job, booknest-smoke, built once on it and printed BookNest smoke test on Jenkins 2.555.3 8,793 . Then:
docker stop l2-jenkins-upg && docker rm l2-jenkins-upg
docker run -d --name l2-jenkins-upg -p 127.0.0.1:32082:8080 \
-e JAVA_OPTS=-Djenkins.install.runSetupWizard=false \
-v l2-jenkins-upg-home:/var/jenkins_home jenkins/jenkins:2.568.3-lts-jdk21
sleep 20
docker logs l2-jenkins-upg 2>&1 | grep -oE '(Upgraded Jenkins from|Jenkins is fully).*'l2-jenkins-upg l2-jenkins-upg ... Upgraded Jenkins from version 2.555.3 to version 2.568.3. Loaded detached plugins (and dependencies): [] Jenkins is fully up and running
Build 2 of booknest-smoke printed on Jenkins 2.568.3, build 1 was still in its history, and the core warnings of Patching Plugins were gone. A real controller adds three steps: take a backup first (Backing Up JENKINS_HOME), update the plugins right after the core (with plugins.txt, rebuild the image with both), and keep the old image tag, because rolling back means starting the old image on the backup: once the new version has saved its files, older cores may not read them.