2.401.1

[NotMyFault]

Next LTS release

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

Release Lead

@NotMyFault

Prep work

• LTS baseline discussed and selected in the Jenkins developers mailing list.
  https://groups.google.com/g/jenkinsci-dev/c/01Lr3jYtUG4

• Create or update release branch in jenkinsci/jenkins, e.g. stable-2.387, use the init-lts-line script or carry out the equivalent steps therein.

• Create or update release branch in jenkins-infra/release, e.g. stable-2.387.
  #376

  • Modify the RELEASE_GIT_BRANCH and JENKINS_VERSION values in the environment file (profile.d/stable) to match the release.
  • Modify the PACKAGING_GIT_BRANCH value in the packaging script (Jenkinsfile.d/core/package) to match the release.
  • For more info, refer to stable.

• Create or update release branch in jenkinsci/packaging, e.g. stable-2.387.

• 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.
  jenkinsci/bom#2071

• Review Jira and GitHub pull requests for additional LTS candidates, adding the lts-candidate label, and ensure that all tickets are resolved in Jira.

• Backporting announcement email - generate-backporting-announcement script.
  https://groups.google.com/g/jenkinsci-dev/c/sZY2WXoWLWM

• Update Jira labels for lts-candidate issues, 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 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.
  jenkinsci/jenkins#8003

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

  • the selected Jira lts-candidates.
  • possible LTS candidates in the release repository.
  • possible LTS candidates in the packaging repository.

• Review ATH and bom integration tests results.

• 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.

• Send announcement email, example.

• 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.

LTS release

• 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 and #jenkins-infra IRC channels

• Run job on release.ci.jenkins.io if no security release for Jenkins is planned.

• Check LTS changelog is visible on the downloads site.

• Publish GitHub release pointing to LTS changelog, sample.

• Confirm Datadog checks are passing.

• 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).

• 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).

• Adjust state and Released As of Jira issues fixed in the release (see the changelog for issue links).

• Create pull request to update the lts Maven profile in ATH to the newly released version

• Run trusted.ci.jenkins.io Docker image creation job.

• Confirm that the images are available at Docker hub.

• 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.