You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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: 19th March 2024
The release champion for this release is: Scott Fryer
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
Release Champion named whose responsibility is to ensure every item in this checklist gets 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 - JDK22.0.0
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
Restore aqa-tests release branch testenv.properties JDK_BRANCH values to the "-ga" tag after dry-run has completed
Perform TCK Auto-manuals on x64Linux for each dry-run version
One Week 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"
Check the nagios server to ensure there are no critical infrastructure issues
Trigger a trial release pipeline dry-run to ensure less surprises on release day (typically against a milestone build), see here for details
Confirm successful trial release pipelines and successful jck completion
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 Should no longer be needed for main openjdk branches, still need to pay attention to arm32 JDK8 which does not follow predictable tagging.
Run Setup_JCK_Multinode with CLEAN_DIR=true for ( ci.role.test )
Disable Setup_JCK_Run_Multinode To Ensure Test Evidence Is Not Lost
As detailed earlier, again check the nagios server to ensure there are no critical infrastructure issues
Create the Github Issues for tracking progress against each Java version in the adoptium/temurin repo
Create the Github issues for the Adoptium public retro & TC retro in the adoptium/temurin repo
Update the links on the slack channel for the release status and retrospective issues.
Release Day Onwards
Check Tags have been released upstream - Look for mailing list announcements and -ga tags in version control.
Check the published GA tags are the "expected" tags entered in the aqa-tests release branch testenv.properties. If they are not then update. No longer needed and a dup of step above 'Calculate the "expected" openjdk build tags', Will only need to update arm32 JDK8, as the branch it lives in does not follow same tagging rules as others.
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.
jdk8 pipeline(s):
primary jdk8 pipeline:
rerun(s):
secondary jdk8 pipeline:
reruns(s):
jdk11 pipeline(s):
primary jdk11 pipeline:
rerun(s):
secondary jdk11 pipeline:
rerun(s):
jdkxx pipeline(s):
primary jdkxx pipeline:
rerun(s):
secondary jdkxx 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) in the aqa-tests release branch that needs to be updated. Not required for this release
Add links to the status doc to indicate per-platform builds ready
Check it was automatically published to the website.
Announce that we target releases to be available within 48-72 hours of the GA tags being available.
Remind TCK testers (via Slack comment) to update a TCK triage issue with ownership and machine IP before running any interactive/automanual tests.
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.
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.
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 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)
Think the only thing that remains is the update to the support page, fyi @sxa you can close this checklist issue after you are done with it
Update support page (automate* github workflow to create a PR to update support webpage) @sxa volunteered to do so, as he was also going to update to include RISC-V
NOTE: Items marked
jdkxx
andTEMPLATE_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: 19th March 2024
The release champion for this release is: Scott Fryer
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
Release Champion named whose responsibility is to ensure every item in this checklist gets 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 - JDK22.0.0
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 - aqa-tests branch name is v1.0.1-release
Ensure ALL nodes online prior to running these following TC steps:
ALL OK - Except jck-skytap-aix72-ppc64-3 which is clean, but had issues with git, issue logged with EF Infra
https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/4419 NOW RESOLVED
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
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
https://ci.adoptium.net/job/build-scripts/job/utils/job/release-pipeline-generator/56/
Prepare & Perform Dry Run Of Build & Tests : Dry-run
https://ci.adoptium.net/job/build-scripts/job/release-openjdk22-pipeline/4/
Triage dry-run TCK job results
Restore aqa-tests release branch testenv.properties JDK_BRANCH values to the "-ga" tag after dry-run has completed
Perform TCK Auto-manuals on x64Linux for each dry-run versionOne Week Prior To Release
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
Wait For All Of The Above To Complete Successfully Before Proceeding!
Log a helpdesk ticket with EF , to get all test materials updated
https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/4437
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
Trigger a trial release pipeline dry-run to ensure less surprises on release day (typically against a milestone build), see here for detailsConfirm successful trial release pipelines and successful jck completionCalculate 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.propertiesShould no longer be needed for main openjdk branches, still need to pay attention to arm32 JDK8 which does not follow predictable tagging.Release Week Checklist:
- [X]
Release Day Onwards
Check Tags have been released upstream - Look for mailing list announcements and
-ga
tags in version control.Check the published GA tags are the "expected" tags entered in the aqa-tests release branch testenv.properties. If they are not then update.No longer needed and a dup of step above 'Calculate the "expected" openjdk build tags', Will only need to update arm32 JDK8, as the branch it lives in does not follow same tagging rules as others.Check Tags have been Mirrored Mirrors.
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.
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) in the aqa-tests release branch that needs to be updated.Not required for this releaseAdd links to the status doc to indicate per-platform builds ready
Add website banner
Remind TCK testers (via Slack comment) to update a TCK triage issue with ownership and machine IP before running any interactive/automanual tests.
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.
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.
Fix blocking failures if they exist and confirm others are non-blocking.
Confirm Temurin-compliance items completed, per platform/version/binaryType
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/ ) https://ci.adoptium.net/job/build-scripts/job/release/job/create_release_notes/72/
Publish the release (Find the quick links at the bottom of the Jenkins release pipeline job and run the restricted access release tool job on Jenkins) ( also publish release notes - Done: https://github.com/adoptium/temurin22-binaries/releases/download/jdk-22%2B36/OpenJDK22U-jdk-release-notes_22_36.json)
Consider updating the API as required via the relevant parts of the Adoptium API model constants.
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 support webpage) Various updates to the supported platforms page for JDK22, RISC-V and others adoptium.net#2760
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 beif: 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 ArchiveJCK_RunResults/31/ -> temurin-compliance-results/releases/tag/2024_March
Publish AQAvit TAP files to the relevant releases repositories - documentation forth-coming, combine the artifact from TAP_verification/53 with Grinder TAP files (19 gathered from triage activity at March 2024 JDK22 Release Triage aqa-tests#5156 (comment)) and upload via this run refactor_openjdk_release_tool/8457 to push to binaries repo (here)
Use EclipseMirror job in the Temurin Compliance jenkins to store a backup of the release artifacts (EclipseMirror/78)
Declare the release complete and close this issue
Create an issue 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. see Create Eclipse Temurin April 2024 CPU blog post adoptium.net#2756
The text was updated successfully, but these errors were encountered: