LTS 2.568.3 release checklist

[krisstern]

LTS 2.568.3 release

More information about the release process is available on the release guide.

RC release date: August 19th, 2026
Release date: September 2nd, 2026

Previous release checklist: #935

Release Lead

@krisstern

Prep work

• LTS baseline discussed and selected in the Jenkins developers mailing list.
  If the last release of the preceding LTS line is a security release, consider making the matching weekly release the new LTS baseline.
  For example, 2.462.3 LTS and 2.479 were security releases and it is simpler to use 2.479 as baseline than 2.477.

• Create or update the release branches in all the repositories below, e.g. stable-2.387 with the init-lts-line script or carry out the equivalent steps therein. For more info, refer to stable.

  • jenkinsci/jenkins
  • jenkinsci/packaging
  • jenkinsci/docker
  • jenkins-infra/release

• Check with the Jenkins Infrastructure team for backports on repositories jenkinsci/packaging, jenkinsci/docker and jenkins-infra/release as per https://github.com/jenkins-infra/release/blob/master/docs/releases.md#open-a-backporting-pr.

  • A message one or two weeks before the final LTS release in the Matrix channel #jenkins-infra mentioning this issue and this item is enough: they will own the backports

• Create a pull request to update bom to the weekly version that will be the base of the release line (and strike this out for new point release).
  Assure that the bom-weekly version number is already testing the base of the release line or a version newer than the base of the release line.

• Review recent security advisories for fixes in Jenkins weeklies after the LTS baseline, and ensure there are issues for their backport.

• Review GitHub issues and pull requests for additional LTS candidates, adding the lts-candidate label. Ensure that all issues are resolved.

• Send a backporting announcement email to the jenkinsci-dev mailing list, using the default template.
  Remember to exchange the LTS version, release date and issue URLs.

  • https://groups.google.com/g/jenkinsci-dev/c/NwM4_VIlKSc/m/o8LXX19uCQAJ

• Update labels for lts-candidates, either add 2.387.2-fixed and remove lts-candidate or add 2.387.2-rejected, and retain lts-candidate.

• Backport changes, run the list-issue-commits script to locate commits of interest, some manual work is required to locate them if the issue ID wasn't present at merge time, backport with git cherry-pick -x $commit.

• Open backporting PR with into-lts label and summary of changes in description from lts-candidate-stats script and:

  • the selected lts-candidates
  • By the Jenkins Infrastructure team:
    • possible LTS candidates in the release repository.
    • possible LTS candidates in the packaging repository.
    • possible LTS candidates in the docker controller repository.

• Open a pull request towards the acceptance test harness and plugin compatibility test to confirm the incremental produced by the backporting PR doesn't contain regressions.
  The documentation explains which profiles you have to modify in your PR.

• Prepare LTS changelog based on the style guide using the changelog generator - This is normally done by the docs team, ask in gitter.

• Prepare LTS upgrade guide based on previous upgrade guides - This is normally done by the docs team, ask in gitter.

RC creation

• Merge backporting PR in jenkinci/jenkins using a merge commit (and do not squash).

• Retrieve the URL for the RC from the commit status (Jenkins Incrementals Publisher / Incrementals) of the last build on the stable branch (requires a passing build). Visit the jenkins-war URL and copy the URL of the war file, which would be something like https://repo.jenkins-ci.org/incrementals/org/jenkins-ci/main/jenkins-war/2.387.1-rc32701.b_06d9cef554c/jenkins-war-2.387.1-rc32701.b_06d9cef554c.war. If the incrementals are broken you can deploy a build from your own machine with mvn -e clean deploy -DskipTests=true.

• Publish a pre-release Github release, e.g. sample currently we don't have a changelog for RCs.

• Confirm the automatic announcement has been sent to the jenkinsci-dev mailing list and community forums. If the automatic announcement is not sent, compose and send the announcement yourself.

• Check with security team that no security update is planned. If a security update is planned, revise the checklist after the public pre-announcement to the jenkinsci-advisories mailing list.

• For a new LTS baseline's ".1" release, if there were recent security advisories for fixes in Jenkins weeklies after the LTS baseline that had to be backported:

  • Update those advisories to mention the new 2.xxx.1 LTS release as an additional fix version (example)
  • Update warnings metadata to exclude the ".1" release (example)
  • Inform the Jenkins security team about the need to update CVE metadata to exclude the new LTS line from affected version ranges.

LTS release

• Check with the Jenkins Infrastructure team that backports on repositories jenkinsci/packaging, jenkinsci/docker and jenkins-infra/release are completed and merged.

  • A message two days prior to the release in the Matrix channel #jenkins-infra mentioning this issue and this item is enough

• Ensure JENKINS_VERSION is updated to the proper version in the packaging profile: https://github.com/jenkins-infra/release/blob/stable-2.xxx/profile.d/stable

• Publish changelog (one day prior to the release in case of a security update).

• Announce the start of the LTS release process in the #jenkins-release:matrix.org channel.

• Trigger https://release.ci.jenkins.io/job/infra-agents-health/job/master to check that agents can be provisioned without issue and notify the Jenkins Infrastructure team if it's not passing

• If this is the first release of a new LTS line (otherwise you can ignore this bullet), we have two pipelines which will fail on their first run on the stable-xxx branches. You have to run them both, only once for their first build (so they can parse their parameters) and cancel them after a few seconds (the button "Build" of the branch page should then change to "Build with Parameters" after reloading the page):

  • "Child" pipeline https://release.ci.jenkins.io/job/core/job/release/ on its stable-xxx branch.
  • "Child" pipeline https://release.ci.jenkins.io/job/core/job/package/ on its stable-xxx branch.

• Launch the "Parent" job ("Stable" -> "Release") on release.ci.jenkins.io/job/core/job/stable/job/release/ if no security release for Jenkins is planned.

  • The first "child" pipeline ("Core" -> "Core Release") triggered by the "parent" expects a human review and approval. Please check its "Plan" stage carefully (you can compare with previous stable line build) and use the approval to start the release build.
  • The second "child" pipeline (("Core" -> "Core Package") will also require a human approval once the "Core Release" is finished, as it's started automatically by the "Parent" pipeline.
  • Note: if the "Parent" pipeline has not been used or failed, please ask for help in the jenkinsci/release channel

• Wait for successful job completion (release: ~3 to 4 hours, packaging ~30 minutes).

• Check LTS changelog is visible on the downloads site.

• Publish GitHub release pointing to LTS changelog, sample.

• Confirm that all Packages are available on the Datadog page.

• Confirm the Debian installer acceptance test is passing.
  For good measures, check the console log to confirm that the correct release package was used (e.g. search for 2.387. If not, launch tests again).

• Confirm the Red Hat installer acceptance test is passing.
  For good measures, check the console log to confirm that the correct release package was used (e.g. search for 2.387. If not, launch tests again).

• Create pull request to update the jenkins.version in the most recent release profile in plugin BOM to the newly released version.
  Refer to first step before the release and second step after the release for examples

• Create a tag matching the LTS release you create in the docker repository.

• Check that all agents are available and running properly in https://trusted.ci.jenkins.io/job/acceptance-tests-check-agent-availability

  • Ask Jenkins infra team to confirm availability if you don't have access to this job

• If https://trusted.ci.jenkins.io/job/Containers/job/Controller job is disabled:

  • Confirm with the Jenkins Infrastructure team that it can be enabled with a message in #jenkins-infra
  • Enable it
  • Trigger a scan repository and watch for triggered jobs (cancel those of old tags if any)
  • Wait for the build completion
  • Disable the job again

• Confirm that the images are available at Docker hub.

• Publish docker controller GitHub release.

• Merge the PR generated by the jenkins-dependency-updater bot in the jenkinsci/helm-charts repository.

• Create a helpdesk ticket to update ci.jenkins.io, trusted.ci, cert.ci and release.ci to the new LTS release, example.

• Send email asking for the next release lead, example, dates for the next one can be found on the Jenkins calendar.