Checklist for Temurin Release 17.0.11+9 on Linux/riscv64

[sxa]

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: _____

The release champion for this release is: @sxa

Planned absences during the release cycle:

The role of the release champion is to ensure that all release activities listed in this checklist get completed (by delegation to the broader team or by the release champion themselves). The final task of the release champion during a release is to confirm that all items in the checklist were completed satisfactorily and the release can be declared complete.

Everyone participating in a release, including the release champion are requested to provide feedback into the release retrospective so that the release process can be continuously improved (through simplification and/or automation).

NOTE: Checklist has been cut down as the pre-release week parts are not required here as we are releasing and existing tag

---

Release Day Onwards

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

• [x] Check the published GA tags are the "expected" tags entered in the aqa-tests release branch testenv.properties. If they are not then update.

• [x] Check Tags have been Mirrored Mirrors.

• [x] Check "auto-trigger" pipelines or Launch build pipelines for each version being released. Verify if the release pipline "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.

  • LTS jdk17 pipeline(s):
  • primary jdk17 pipeline: https://ci.adoptium.net/job/build-scripts/job/release-openjdk17-pipeline/66/
    • rerun(s):
  • secondary jdk17 pipeline (inc. Win32):
    • rerun(s):

• [ ] Add links to the status doc to indicate per-platform builds ready

• [x] Summarize test results. Find each launched build pipeline in TRSS to view a summary of test results. Can use the Release Summary Report feature in TRSS to generate a summary of failures, history and possible issues in markup format to be added to this issue as a comment.

• [x] Triage each build and test failure in the release summary report (following the Triage guidelines) and determine blocking or non-blocking. Supply links to triage issues or docs for each version here.

  • LTS jdk17 triage summary: https://github.com/adoptium/temurin-build/issues/3591#issuecomment-2104717954

• [ ] Fix blocking failures if they exist and confirm others are non-blocking.

• [x] Confirm Temurin-compliance items completed, per platform/version/binaryType

• [x] Get PMC 'ready to publish' approval, once no blocking failures exist.

• [ ] Generate The Release Notes Per JDK Version , ( Use https://ci.adoptium.net/job/build-scripts/job/release/job/create_release_notes/ ) and publish them with the release tool using UPSTREAM_JOB_NAME of create_release_notes and the appropriate JOB NUMBER

• [ ] **Verify that the release notes are live - may require a full update on the API we've had problems with this recently) and remediate if required.

• [x] Publish the release (run the restricted access release tool job on Jenkins) ( also publish release notes )

• [ ] Consider updating the API as required via the relevant parts of the Adoptium API model constants.

• [x] Verify binaries published successfully to github releases repo and website (automate*, this could also be an automated test)

• [ ] Publish updates to the containers to dockerhub

• [ ] Edit the Homebrew Temurin Cask and replace the version and sha256 as appropriate. This means for Homebrew users that they install the latest by default and can use the @ notation to install older versions if they wish.

• [ ] 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 needed if they have changed in this release. Create a PR to Supported platforms

• [ ] Update release notes (automate* - github workflow to create update for release notes pages - example)

• [ ] Trigger linux installers pipeline currently it is part of the build pipelines (will eventually be updated to run independently)

• [ ] Publicize the release via Slack #release channel and Twitter (can be partially automated)

• [ ] Declare code freeze end opening up the code for further development

• [ ] Disable code freeze bot In order to enable the code freeze GitHub you need to change the line if: github.repository_owner == 'adoptium' && true to be if: github.repository_owner == 'adoptium' && false in the code-freeze.yml GitHub workflow. Please contact the PMC if you need help merging this change.

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

• [ ] Check for presence of jdk8u aarch32 GA tag and mirror it Mercurial repo - Mirror job

• [ ] Do all of the above for the jdk8u/aarch32 build: Ensure to specify overridePublishName param

• [ ] Archive/upload all TCK results

• [ ] Use EclipseMirror job in the Temurin Compliance jenkins to store a backup of the release artifacts

• [ ] Create a draft PR for a release blog post for next release in the adoptium.net repository and ensure to delegate the task of finalizing and publishing the existing draft 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

[sxa]

JDK17+ is now part of the regular release cycle, therefore closing.