Checklist for Temurin Release March 2026

[Haroon-Khel]

NOTE: Items marked jdkxx and TEMPLATE_UPDATEME should be replaced while deploying this issue template. It is recommended to delete this line once you've done so :-)

This Temurin release checklist based on the release doc captures what activities must happen during a release.

The target release date is: 17/3/2025

The release champion for this release is: @Haroon-Khel

The compliance release lead (CRL) for this release is: @vieiro

Planned absences during the release cycle:

The release champion ensures that all release tasks listed below get completed (directly or by delegation).
Their final task is to confirm that all tasks below are completed to a high standard, and that the release can be declared complete.

Everyone involved in a release is asked to provide feedback via the retrospective for future improvement/automation.

---

Two Weeks Prior To Release

• Release Champion named whose responsibility is to ensure every item in this checklist gets completed
• Compliance Release Lead named whose responsibility is to ensure Temurin Compliance items marked with TC get completed
• Release Checklist Created Create this issue to track the release and the preparation tasks.
• Identify Expected Release Versions - Find out the version numbers from here
• Notify release branching of build repositories : Slack message, branching build repositories
• Create build repositories release Branches : Create build repository release branches
• Identify the aqa branch name for the upcoming release (Note, April and October PSU updates generally use same branch as the March/September new releases v1.0.12-release
• Check that the temurin updater action has not been suspended. If it has, re-enable it or set a reminder to run manually when ready.

1-1½ weeks prior to release

1½ weeks would typically mean running on the Friday so the dry-run(and potential "candidate" build) results are available on the Monday before release week.

CRL to ensure these TC steps are done (please complete steps in order, and ensure jobs have finished before proceeding to next step):

• TC: Ensure ALL nodes are online. Nodes list.
• TC: Run ProcessCheckMultiNode to remove old test processes.
• TC: Run DeleteJCKMultiNode to remove now-redundent jck versions.
• TC: Run DeleteNonJenkinsTestFiles to remove any old test workspaces. Report any "ERROR:" to users for folder deletion.
• TC: Run Gather_Host_Info to check all nodes have sufficient disk space and iNodes. If any nodes are found lacking, review and resolve.
• TC: Run Setup_JCK_Run_Multinode to update jck_run folders and jtx exclude files.
• TC: Run DeleteWorkspaces to clean up any lingering jenkins job materials.

• Check the nagios server to ensure there are no critical infrastructure issues
  Log in to the public nagios server, and check the Problems / Services page. If you do not have access, please request it via an issue in the infrastructure repository. If there are any issues, then please log an issue in the infrastructure repository.
• Regenerate The Release Build Pipeline Jobs In Jenkins
• Update testenv.properties in the AQA release branch to use the -dryrun-ga branches (Sample PR)
• Prepare & Perform Dry Run/Candidate Build & Tests : Dry-run
• TC: Triage dry-run/candidate TCK job results
• Restore aqa-tests release branch testenv.properties JDK_BRANCH values to the "-ga" tag after dry-run/candidate has completed
• TC: (Optional based on perceived risk with any machine updates) Perform TCK Auto-manuals on one platform

Thursday or Friday prior to release

• Final Code Freeze Warning post a message to the build & release slack channels : Slack message

After 1 day, then :-

• Declare code freeze to ensure stability of build systems and infrastructure during release process : #build and #release slack message: "Code Freeze is now being enabled"

• Enable code freeze bot : Enabling code freeze

• Prepare For Release

  • Ensure that there is an aqa-tests branch that matches the name of the latest aqa-tests release version.
  • Update releaseVersions with release versions.
  • Update releasePlan.cfg with expected tags, for more detail see here.
  • Generate release pipeline jobs with release-pipeline-generator.
    • DO NOT use default job parameter values. aqaReference should be the latest aqa-tests release version.

Wait For All Of The Above To Complete Successfully Before Proceeding!

• TC: Log a helpdesk ticket with EF, to get all test materials updated and prepare for any manual activities
• TC: Run the ProcessCheckMultiNode process cleaning job on all ci.role.test nodes, to ensure healthy state, verify all nodes successful: https://ci.eclipse.org/temurin-compliance/job/ProcessCheckMultiNode/build?delay=0sec
• TC: Run the Setup_JCK_Run_Multinode job with CLEAN_DIR=true (to purge any old release contents/results) on all ci.role.test nodes, this will extract the jck_run folder with all the temurin.jtx exclude files, verify all nodes successful : https://ci.eclipse.org/temurin-compliance/job/Setup_JCK_Run_Multinode/build?delay=0sec
• Check the nagios server to ensure there are no critical infrastructure issues

---

Release Week Checklist:

• TC: Check All Nodes Online https://ci.eclipse.org/temurin-compliance/label/ci.role.test/
• TC: Run ProcessCheckMultiNode with default parameters.
• TC: Run Setup_JCK_Run_Multinode with CLEAN_DIR=true for (ci.role.test).
• TC: Disable Setup_JCK_Run_Multinode preserve test evidence.
• As detailed earlier, again check the nagios server to ensure there are no critical infrastructure issues.
• Create the Github Issues for tracking progress in the adoptium/temurin repo
• Create the Github issues for the Adoptium public retro in the adoptium/temurin repo
• TC: Create the retrospective issue for the Temurin Compliance project.
• Update the links on the slack channel for the release status and retrospective issues.
• Remove x32Windows from release-openjdk{8,11,17}-pipeline (they will be manually triggered later as secondary pipelines).
• Check for any last minute cacerts updates and cherry-pick to temurin-build release branch if needed.

Release Day Onwards

• Check Tags have been released upstream - Look for mailing list announcements and -ga tags in version control.

• Check Tags have been Mirrored Mirrors.

• Check "auto-trigger" pipelines or Launch build pipelines for each version being released. Verify if the release pipeline "auto-triggered", if not (maybe expected tag was wrong), then manually launch (as per release doc) once release tags are available via launch page in Jenkins. Provide links in this issue to each version's pipeline build(s). There may be multiple pipelines per version if primary and secondary platforms are separated to expedite the release. In some cases, where there are unforeseen configuration or infrastructure issues, reruns may be needed.

  • STS jdk26 pipeline(s):
    • primary jdk26 pipeline:
      • rerun(s):
    • secondary jdk26 pipeline:
      • rerun(s):

• Check Upstream Tags, Mirror Tags & Trigger Builds For JDK8 AARCH32 This specific version is built from a separate mirror repository and has a separate build process; this is CURRENTLY not part of the automation which is handled for the other platforms and version. Also note that there is a separate properties file (testenv_arm32.properties) which needs to be updated.

• Add links to the status doc to indicate that the per-platform builds are ready.

• Add website banner.

  • Make a PR.
  • Check it was automatically published to the website.
  • Announce that we target releases to be available within:
    • New release: 48 hours (primaries) or 7 days (secondaries) of the new TCK material being made available to us.
    • Update release: 48-72 hours of the GA tags being available.

• TC: Remind TCK testers (via Slack comment) to update a TCK triage issue with ownership and machine IP before running any interactive/automanual tests.

• Monitor and assist the team during test triage (process outlined below)

  • Summarise test results. Find each launched build pipeline in TRSS to view a summary of test results.
  • Use the Release Summary Report feature in TRSS to generate a summary of failures, history and possible issues in markup format.
  • Add the Test Summary to a new aqa-tests issue, if one does not already exist.
  • Triage each build and test failure in the release summary report (following the Triage guidelines) and label them as blocking or non-blocking.
  • Fix blocking failures if they exist and confirm others are non-blocking.

• Supply links to triage issues for each version being released.

  • STS jdk26 triage summary:

• TC: Confirm Temurin-compliance items completed, per platform/version/binaryType.

• Help team follow the per-platform publishing process. See "Publish build results" here for details.

• Generate The Release Notes Per JDK Version using create_release_notes

• Publish the release notes via the release tool. Set UPSTREAM_JOB_NAME to "create_release_notes", and set JOB_NUMBER to the create_release_notes job number.

• Verify that the release notes are live

  • This may require a full update on the API. See here for details.

• Publish updates to the container images to dockerhub.

• Check that the homebrew casks for macos have been automatically updated. Details here (Section "4.1. [Mac only]").

• Update support page. (automate* github workflow to create a PR to update the versions and dates on the support table)

• Update supported platforms tables if they have changed in this release. Details here, search for "supported platforms table".

• Check the Linux installer publishing jobs have worked This will be triggered automatically by the release tool job, but its status should be checked.

• Post the Release Blog via PR. Past Example.

• Publicise the release via Slack #release channel and Twitter. See step 7 [here][publish] for details. (automate* - can be partially automated).
  [publish]: https://github.com/adoptium/temurin-build/blob/master/RELEASING.md#at-ga-time

• Declare code freeze end; opening up the code for further development.

• Disable code freeze bot.

• Remove website banner. (automate* via github workflow in website repository)

• Check for the presence of the jdk8u aarch32 GA tag and mirror it. Upstream Git repo. - Mirror job

• Do all of the above for the jdk8u/aarch32 build (make sure you specify the overridePublishName parameter).

• TC: Archive/upload all TCK results.

• Archive/upload all AQA results Search for Publish AQA test results in RELEASING.md for the process.

• TC: Use EclipseMirror job in the Temurin Compliance jenkins to store a backup of the release artifacts.

• Run [download_and_sbom_validation job] to verify the downloads, signatures and SBOM contents.
  [download_and_sbom_validation job]: https://ci.adoptium.net/job/build-scripts/job/release/job/download_and_sbom_validation

• Create an issue to capture notes for the next release blog in the adoptium.net repository and ensure to delegate the task of finalising and publishing a PR for this release's blog post. (Use this link to get the vulnerability list).

• Ensure the adoptium calendar is updated for the next cycle at a minimum

• Declare the release complete and close this issue.