[RELEASE] Release version 2.10.0

[github-actions]

Release OpenSearch and OpenSearch Dashboards 2.10.0

I noticed that a manifest was automatically created in manifests/2.10.0. Please follow the following checklist to make a release.

How to use this issue

This Release Issue

This issue captures the state of the OpenSearch release, its assignee is responsible for driving the release. Please contact them or @mention them on this issue for help. There are linked issues on components of the release where individual components can be tracked. More details are included in the Maintainers Release owner section.

Release Steps

There are several steps to the release process, these steps are completed as the whole release and components that are behind present risk to the release. The release owner completes the tasks in this ticket, whereas component owners resolve tasks on their ticket in their repositories.

Steps have completion dates for coordinating efforts between the components of a release; components can start as soon as they are ready far in advance of a future release.

Component List

To aid in understanding the state of the release there is a table with status indicating each component state. This is updated based on the status of the component issues.

Preparation

• Assign this issue to a release owner.
• Declare a pencils down date for new features to be merged.
• REPLACE_RELEASE-minus-14-days is pencils down date for feature freeze.
• Update the Campaigns section to include monitoring campaigns during this release.
• Update this issue so all __REPLACE_RELEASE-__ placeholders have actual dates.
• Document any new quality requirements or changes.
• Finalize scope and feature set and update the Public Roadmap.
• Create a release issue in every component repo based on component release issue template and link back to this issue, update Components section with these links.
• Ensure the label is created in each component repo for this new version, and the next minor release. Create a version label
• Ensure that all release issues created above are assigned to an owner in the component team.
• Increase the build frequency for the this release from once a day (H 1 * * *) to once every hour (H/60 * * * *) in jenkinsFile.

Campaigns

REPLACE with OpenSearch wide initiatives to improve quality and consistency.

Release Branch - _Ends REPLACE_RELEASE-minus-14-days

• Component versions are auto-incremented to 2.10.0 version.
• Plugins team to ensure working CI in component repositories and merge the version increment PRs.
• OpenSearch / OpenSearch-Dashboards core cut branch <MajorVersion>.<MinorVersion> early.
• All component repos create <MajorVersion>.<MinorVersion> branch for the release.

Feature Freeze - _Ends REPLACE_RELEASE-minus-12-days

• OpenSearch / OpenSearch-Dashboards core and components teams finalize their features.
• Create Jenkins workflows that run daily snapshot builds for OpenSearch and OpenSearch Dashboards.
• Make pull requests to add each component to manifests/2.10.0/opensearch-2.10.0.yml and manifests/2.10.0/opensearch-dashboards-2.10.0.yml with the corresponding checks.

Code Complete - Ends REPLACE_RELEASE-minus-10-days

• Code Complete: Make sure that the code for this specific version of the release is ready and the branch corresponding to this release has been added to this release version manifest.
• Verify pull requests to add each component to manifests/2.10.0/opensearch-2.10.0.yml and manifests/2.10.0/opensearch-dashboards-2.10.0.yml have been merged.
• Gather, review and combine the release notes from components repositories.

Release testing - Ends REPLACE_RELEASE-minus-6-days

• Declare a release candidate build, and provide the instructions with the release candidates for teams on testing (REPLACE_RELEASE-minus-8-days).
• Stop builds for this version of OpenSearch and/or OpenSearch Dashboards in order to avoid accidental commits going in unknowingly. Restart only if necessary else manually run the build workflow and declare new release candidate.
• After generate the release candidates, raise PR to lock input manifest refs of both OS and OSD builds with the commit ids from distribution manifest of the release candidates.
• Sanity Testing (REPLACE_RELEASE-minus-8-days - REPLACE_RELEASE-minus-6-days): Sanity testing and fixing of critical issues found by teams. Teams test their components within the distribution, ensuring integration, backwards compatibility, and perf tests pass.
• Publish all test results in the comments of this issue.

Performance testing validation - Ends REPLACE_RELEASE-minus-6-days

• Performance tests do not show a regression.
• Longevity tests do not show any issues.

Release - _Ends {_REPLACE_RELEASE-day}

• Verify all issues labeled v2.10.0 in all projects have been resolved.
• Complete documentation for this release.
• Author blog post for this release.
• __REPLACE_RELEASE-minus-1-day - Publish this release on opensearch.org.
• __REPLACE_RELEASE-day - Publish a blog post - release is launched!

Post Release

• Create release tags for each component (Jenkins job name: release-tag-creation).
• Replace refs in manifests/2.10.0 with tags and remove checks.
• If this is a major or minor version release, stop building previous patch version.
• Generate distribution release notes reviewed by PM team for opensearch-build repository.
• Increment version for Helm Charts (sample PR) for the 2.10.0 release.
• Increment version for Ansible Charts (sample PR) for the 2.10.0 release.
• Prepare for next patch release by incrementing patch versions for each component.
• Update this template with any new or missed steps.
• Create an issue for a retrospective, solicit feedback, and publish a summary.

Components

Replace with links to all component tracking issues.

Component	On track	Release Notes
{COMPONENT_ISSUE_LINK}	{INDICATOR}}	{STATUS}

Legend

Symbol	Meaning
🟢	On track with overall release
🟡	Missed last milestone
🔴	Missed multiple milestones