[x] Create or update release branch in jenkinsci/packaging, e.g. stable-2.462.
[x] Create a pull request to update bom to the weekly version that will be the base of the release line.
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.
[x] Review recent security advisories for fixes in Jenkins weeklies after the LTS baseline, and ensure there are Jira issues for their backport.
[x] Review Jira and GitHub pull requests for additional LTS candidates, adding the lts-candidate label, and ensure that all tickets are resolved in Jira.
[x] Update Jira labels for lts-candidate issues, either add 2.462.1-fixed and remove lts-candidate or add 2.462.1-rejected, and retain lts-candidate.
[x] Backport changes, run the list-issue-commits script to locate commits via Jira ID, 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.
[x] Open backporting PR with into-lts label and summary of changes in description from lts-candidate-stats script and:
[x] 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.
[x] 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:
[x] Update those advisories to mention the new 2.xxx.1 LTS release as an additional fix version (example)
[x] 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).
[x] 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).
[x] Adjust state and Released As of Jira issues fixed in the release (see the changelog for issue links).
[x] Create pull request to update the lts Maven profile in ATH to the newly released version (PR-1664)
[x] Create a tag matching the LTS release you create in the docker repository and publish a GitHub release.
[x] Confirm that the images are available at Docker hub.
[x] Merge the PR generated by the jenkins-dependency-updater bot in the jenkinsci/helm-charts repository.
[x] Create a helpdesk ticket to update ci.jenkins.io, trusted.ci, cert.ci and release.ci to the new LTS release, example.
[x] Send email asking for the next release lead, email message, dates for the next one can be found on the Jenkins calendar.
LTS 2.462.1 release checklist
More information about the release process is available on the release guide.
Release Lead
@MarkEWaite
Prep work
[x] LTS baseline discussed and selected in the Jenkins developers mailing list.
[x] Create or update release branch in jenkinsci/jenkins, e.g.
stable-2.462, use the init-lts-line script or carry out the equivalent steps therein.[x] Create or update release branch in jenkins-infra/release, e.g.
stable-2.462.RELEASE_GIT_BRANCHandJENKINS_VERSIONvalues in the environment file (profile.d/stable) to match the release.PACKAGING_GIT_BRANCHvalue in the packaging script (Jenkinsfile.d/core/package) to match the release.[x] Create or update release branch in jenkinsci/packaging, e.g.
stable-2.462.[x] Create a pull request to update bom to the weekly version that will be the base of the release line. 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.
[x] Review recent security advisories for fixes in Jenkins weeklies after the LTS baseline, and ensure there are Jira issues for their backport.
[x] Review Jira and GitHub pull requests for additional LTS candidates, adding the
lts-candidatelabel, and ensure that all tickets are resolved in Jira.[x] Send a backporting announcement email to the jenkinsci-dev mailing list, using the default template. Remember to exchange the LTS version, release date and Jira URLs.
[x] Update Jira labels for lts-candidate issues, either add
2.462.1-fixedand removelts-candidateor add2.462.1-rejected, and retainlts-candidate.[x] Backport changes, run the list-issue-commits script to locate commits via Jira ID, 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.[x] Open backporting PR with
into-ltslabel and summary of changes in description from lts-candidate-stats script and:[x] Open an acceptance test harness pull request (PR-1621) and a plugin compatibility test pull request (PR-3375) 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.
[x] Update the dependabot branch target in jenkinsci/jenkins to the new stable branch (strike this out for new point release).
[x] Prepare LTS changelog based on the style guide using the changelog generator - This is normally done by the docs team, ask in gitter. Refer to PR-7400
[x] Prepare LTS upgrade guide based on previous upgrade guides - This is normally done by the docs team, ask in gitter. Refer to PR-7400
RC creation
[x] Merge backporting PR in
jenkinci/jenkinsusing a merge commit (and do not squash).[x] 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-warURL 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.462.1-rc35045.7a_306482f65c/jenkins-war-2.462.1-rc35045.7a_306482f65c.war[x] Publish a pre-release Github release, e.g. 2.462.1-rc currently we don't have a changelog for RCs.
[x] Confirm the automatic announcement has been sent to the jenkinsci-dev mailing list and community forums.
[x] 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.
[x]
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
[x] Publish changelog (one day prior to the release in case of a security update).
[x] Announce the start of the LTS release process in the #jenkins-release:matrix.org channel.
[x] Run job on release.ci.jenkins.io if no security release for Jenkins is planned.
[x] Check LTS changelog is visible on the downloads site.
[x] Publish GitHub release pointing to LTS changelog, sample.
[x] Confirm Datadog checks are passing.
[x] 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).[x] 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).[x] Adjust state and
Released Asof Jira issues fixed in the release (see the changelog for issue links).[x] Create pull request to update the
ltsMaven profile in ATH to the newly released version (PR-1664)[x] Create a tag matching the LTS release you create in the docker repository and publish a GitHub release.
[x] Confirm that the images are available at Docker hub.
[x] Merge the PR generated by the
jenkins-dependency-updaterbot in the jenkinsci/helm-charts repository.[x] Create a helpdesk ticket to update
ci.jenkins.io,trusted.ci,cert.ciandrelease.cito the new LTS release, example.[x] Send email asking for the next release lead, email message, dates for the next one can be found on the Jenkins calendar.