Checklist for Temurin Release jdk-21+35

[gdams]

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: @gdams

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

---

Two Weeks Prior To Release

• [x] Release Champion named whose responsibility is to ensure every item in this checklist gets completed

• [x] Release Checklist Created Create this issue to track the release and the preparation tasks.

• [x] Identify Expected Release Versions - Find out the version numbers from here

• [x] Notify release branching of build repositories : Slack message, branching build repositories

• [x] Create build repositories release Branches : Create build repository release branches

• [x] Identify the aqa branch name for the upcoming release

Ensure ALL nodes online prior to running these following TC steps:

• [x] TC: Run the DeleteJCKMultiNode process cleaning job on all ci.role.test nodes, to remove any now redundent jck-versions, to ensure healthy state, verify all nodes successful: https://ci.eclipse.org/temurin-compliance/job/DeleteJCKMultiNode

• [x] 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

• [x] 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

• [x] 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.

• [x] Regenerate The Release Build Pipeline Jobs In Jenkins

• [x] Prepare & Perform Dry Run Of Build & Tests : Dry-run

• [x] Triage dry-run TCK job results

• [x] Perform TCK Auto-manuals on x64Linux for each dry-run version

One Week Prior To Release

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

After 1 day, then :-

• [x] 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"

• [x] Enable code freeze bot : Enabling code freeze

• [x] Disable standard builds temporarily; both nightlies and weeklies

  • This frees up resources and ensures no competing jobs during release week.
  • This should be done by running build-pipeline-generator with the default for ENABLE_PIPELINE_SCHEDULE set to false.

• [x] Disable evaluation builds temporarily; both nightlies and weeklies

  • This frees up resources and ensures no competing jobs during release week.
  • This should be done by running evaluation-pipeline-generator with the default for ENABLE_PIPELINE_SCHEDULE set to false.

• [x] Prepare For Release

  • [x] Ensure that there is an aqa-tests branch that matches the name of the latest aqa-tests release version.
  • [x] Update releaseVersions with release versions.
  • [x] Update releasePlan.cfg with expected tags, for more detail see here.
  • [x] 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!

• [x] Log a helpdesk ticket with EF , to get all test materials updated

• [x] 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

• [x] 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

• [x] Check the nagios server to ensure there are no critical infrastructure issues

• [x] Trigger a trial release pipeline dry-run to ensure less surprises on release day (typically against a milestone build), see here for details

• [x] Confirm successful trial release pipelines and successful jck completion

• [x] Calculate the "expected" openjdk build tags for the releases being published, and update all the JDKnn_BRANCH values in the testenv.properties file for the aqa-tests release branch, eg: https://github.com/adoptium/aqa-tests/blob/v0.9.6-release/testenv/testenv.properties

---

Release Week Checklist:

• [x] Add website banner (this is done by making a PR then it gets automate published to website) - Announce that we target releases to be available within 48-72 hours of the GA tags being available
• [x] -- Check All Nodes Online https://ci.eclipse.org/temurin-compliance/label/ci.role.test/
• [x] Run https://ci.eclipse.org/temurin-compliance/job/ProcessCheckMultiNode/ -- with defaults
• [x] Run Setup_JCK_Multinode with CLEAN_DIR=true for ( ci.role.test )
• [x] Disable Setup_JCK_Run_Multinode To Ensure Test Evidence Is Not Lost
• [x] As detailed earlier, again check the nagios server to ensure there are no critical infrastructure issues
• [x] Create the Github Issues for tracking progress against each Java version
• [x] Create the Github issues for the Adoptium public retro & TC retro
• [x] Update the links on the slack channel for the release status and retrospective issues.

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.

  • jdk21 pipeline(s):
  • primary jdk21 pipeline:
    • rerun(s):
  • secondary jdk21 pipeline:
    • rerun(s):

• [x] 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 seperate properties file (testenv_arm32.properties) which needs to be updated.

• [x] 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.

  • jdk21 triage summary:

• [x] 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.

• [x] Generate The Release Notes Per JDK Version , ( Use https://ci.adoptium.net/job/build-scripts/job/release/job/create_release_notes/ )

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

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

• [x] Publish updates to the containers to dockerhub

• [x] 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.

• [x] Update support page (automate* github workflow to create a PR to update support webpage)

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

• [x] 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)

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

• [x] 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.

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

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

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

• [x] Archive/upload all TCK results

• [x] Declare the release complete and close this issue

• [x] Re-enable testing: Once the release is deployed, don't forget to re-enable any testing that was disabled during the release process to ensure that the system is working as expected. This includes unit tests, integration tests, end-to-end tests, and any other testing that was temporarily paused. Be sure to validate that all tests are running successfully before considering the release complete.

[aelgn]

Is there any target date for the java21 release?

[lazystone]

@gdams first of all, huge thanks for all the hard work maintaining JDK builds!

In no way I'd like to hurry maintainers of the project that provides java binaries for free. But this release is kind of special and there are a lot of people waiting for it. I understand that process is a process, but could you give us some rough ETA, so we're not hanging in the dark?

At the moment a lot of users considering either they should wait a bit or move to another JDK provider. So could you give us just a hint please?

[wendigo]

@lazystone According to the communication on Slack, this is blocked by the lack of the TCK (testing harness for vendors that validate JDK build) that should be provided by Oracle along with the JDK 21 source. We have to be patient.

[lazystone]

@lazystone According to the communication on Slack, this is blocked by the lack of the TCK (testing harness for vendors that validate JDK build) that should be provided by Oracle along with the JDK 21 source. We have to be patient.

Thanks for the inside. We are patient, but there is no progress in the ticket, no comments, that it's blocked due to Oracle. I don't think that a lot of "waiters" know about Adoptium slack either. So, in the absence of communication we, users, tend to blame Adoptium of being slow. But now we can blame Oracle instead :)

[wendigo]

Actually, there is a banner on the Temurin site:

[lazystone]

@wendigo I don't want to argue, but that banner wasn't there last week. And this issue is pointed out as one of the tracking progress of JDK 21 builds in other issues and even in twitter.

One comment here would do.

Now we know.

[gdams]

Eclipse Temurin 21 Update

I am writing to provide an update on this issue as many people are eagerly awaiting the release of Eclipse Temurin 21.

The Eclipse Temurin project is currently experiencing a delay in the release of Temurin 21. While we have built and tested the GA release (Based on the jdk-21+35 tag) we do not yet have access to the TCK material that we require to allow us to release it. This is due to the TCK material for OpenJDK 21 being subject to an updated licence compared to earlier versions.

We do not currently have an ETA of when the material will be available to us but we can usually get the primary platforms within a day or two of receiving the material if no failures occur. In the meantime, if you need to perform testing on the new Temurin 21 there are early access builds already available of the jdk-21+35 level, however, these should be considered “not for production use” at present. These can be downloaded from the Adoptium website or via the Adoptium API.

I thank people for their patience and can only apologise on behalf of the Eclipse Adoptium project for the delays that we are seeing. I will provide an update again on this issue once we have unblocked the issue.

[sxa]

New blog post regarding the delay: https://adoptium.net/blog/2023/09/temurin21-delay/ (Also linked from the banner on the web site)

[nikgoodley-ibboost]

Thanks for the updates and the great work generally. For any other interested, eager bystanders who, like me, are wondering how severe the changes may be and wondering what can't be said out loud: it took a little digging to find what the potential differences are (and I don't expect those close to the issues to want to start talking about legal terms) but for those interested the v3 of the agreement is here https://openjdk.org/legal/OCTLA-JDK9+.pdf and the latest v4 is here https://openjdk.org/legal/OCTLA-JDK21+.pdf.

There's a fair bit of new verbiage around limitations in 2.1 and 2.6 but on a casual reading to an untrained eye doesn't appear to be too concerning (and also noting AWS, Microsoft and Azul amongst others have already signed https://openjdk.org/groups/conformance/JckAccess/jck-access.html which gives some comfort "it will be okay" even if no lawyer will sign that off on the basis of others having signed).

[gdams]

Eclipse Temurin 21 Update

We have now unblocked ourselves and expect Temurin 21 binaries to start being published in the next 1-2 days

[gounthar]

Fantastic news, thank you!

[gdams]

Eclipse Temurin 21 Update

Binaries are starting to get published and are now available at https://adoptium.net/temurin/releases/?version=21

Dockerfiles, homebrew and Linux packages may take a little longer

[gounthar]

Thanks a lot, George, that's super cool!