LTS 2.319.1

[cathychan]

Next LTS release

Release Lead

@cathychan

Prep work

• LTS baseline discussed and selected in the Jenkins developers mailing list

• Create or update release branch in jenkinsci/jenkins, e.g. stable-2.277, use the init-lts-line script

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

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

• Create pull request to update bom to the weekly version that will be the base of the release line (strike this out for new point release)

  • Initiate new LTS line (2.319) jenkinsci/bom#722

• Create pull request to update configuration-as-code integration tests to the weekly version that will be the base of the release line (strike this out for new point release)

  • Test with baseline of next LTS release jenkinsci/configuration-as-code-plugin#1788

• 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

• Update jira labels with the selected issues, e.g. 2.277.2-fixed, 2.277.2-rejected

• Backport changes, create a local branch in jenkinsci/jenkins, 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

• Open backporting PR with into-lts label and summary of changes in description from lts-candidate-stats script and the selected Jira lts-candidates

  • Backporting for LTS 2.319.1 jenkinsci/jenkins#5920

• Review ATH, bom and configuration-as-code integration tests results

• Prepare LTS changelog based on the style guide using the changelog generator @MarkEWaite and @dheerajodha agreed to create it. It will not be ready before the release candidate. Should be ready within 7 days of the release candidate

  • 2.319.1 changelog jenkins.io#4730
  • Fix release date in change log jenkins.io#4739

• Prepare LTS upgrade guide based on previous upgrade guides @MarkEWaite and @dheerajodha agreed to create it. It will not be ready before the release candidate. Should be ready within 7 days of the release candidate

  • 2.319.1 changelog jenkins.io#4730

RC creation

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

• Retrieve the url for the RC from the commit status (continuous-integration/jenkins/incrementals) of the last build on the stable branch (requires a passing build). You will get something like https://repo.jenkins-ci.org/incrementals/org/jenkins-ci/main/cli/2.303.2-rc31385.6eec6c02fc3d/, replace cli with jenkins-war, visit the page and copy the URL to the war file, for the earlier example it would be https://repo.jenkins-ci.org/incrementals/org/jenkins-ci/main/jenkins-war/2.303.2-rc31385.6eec6c02fc3d/jenkins-war-2.303.2-rc31385.6eec6c02fc3d.war. If 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)

• Assure that contents of master branch have been merged to the stable branch in the release repository, e.g. stable-2.277

• Assure that contents of master branch have been merged to the stable branch in the packaging repository, e.g. stable-2.277

• Run job on release.ci.jenkins.io

• Check LTS changelog is visible on the downloads site

• Publish GitHub release pointing to LTS changelog

• Confirm Datadog checks are passing

• Confirm the Debian installer acceptance test is passing

• Confirm the Red Hat installer acceptance test is passing

• Adjust state of Jira issues fixed in the release (see the changelog for issue links) and remove the lts-candidate label from Jira issues resolved in the release

• Create pull request to update bom to the newly released version

  • Update LTS tested against to 2.319.1 jenkinsci/bom#747

• Create pull request to update configuration-as-code integration tests to the newly released version

  • Test with latest LTS 2.319.1 jenkinsci/configuration-as-code-plugin#1799

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

• Update ci.jenkins.io to the new LTS release (note: repo is private, requires infra team membership)

[timja]

I've created the origin branches in jenkins, packaging and release as you won't have access

[cathychan]

Current candidates for backporting: the standard LTS Candidates filter + "released as" being 2.320 or empty

I would propose adding

• https://issues.jenkins.io/browse/JENKINS-67032

There is nothing with into-lts in GH: https://github.com/jenkinsci/jenkins/pulls?q=is%3Apr+label%3Ainto-lts+is%3Aopen

@timja WDYT?

[timja]

Sure makes sense, we'll also need https://issues.jenkins.io/browse/JENKINS-66969 (un-released but fairly important UX issue)

[cathychan]

Sounds good. I'll include that.

[cathychan]

Sure makes sense, we'll also need https://issues.jenkins.io/browse/JENKINS-66969 (un-released but fairly important UX issue)

@timja The ticket is still "open". Do we typically wait for it to be released in the weekly before marking it as resolved, or do we just resolve it now (for it to accurately show up at https://issues.jenkins.io/issues/?filter=12146)?

[timja]

I've updated it now, generally you'd wait but it's getting released tomorrow, so close enough I think

[cathychan]

@timja Can you publish the pre-release? I don't think I have the necessary permissions. (Or I'm not looking at the right place?)

[timja]

https://github.com/jenkinsci/jenkins/releases/tag/jenkins-2.319.1-rc