Skip to content

Latest commit

 

History

History
108 lines (75 loc) · 7.15 KB

release_template.md

File metadata and controls

108 lines (75 loc) · 7.15 KB
Raw
name title labels
Release
[RELEASE] Release version {{ env.VERSION }}
untriaged, release, v{{ env.VERSION }}

Release OpenSearch and OpenSearch Dashboards {{ env.VERSION }}

I noticed that a manifest was automatically created in [manifests/{{ env.VERSION }}](/opensearch-project/opensearch-build/tree/main/manifests/{{ env.VERSION }}). 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 that links 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.

CI/CD (Feature Freeze) - _Ends REPLACE_RELEASE-minus-14-days

  • Create Jenkins workflows that run daily snapshot builds for OpenSearch and OpenSearch Dashboards.
  • Increment each component version to {{ env.VERSION }} and ensure working CI in component repositories.
  • Make pull requests to add each component to [manifests/{{ env.VERSION }}/opensearch-{{ env.VERSION }}.yml](/opensearch-project/opensearch-build/tree/main/manifests/{{ env.VERSION }}/opensearch-{{ env.VERSION }}.yml) and [manifests/{{ env.VERSION }}/opensearch-dashboards-{{ env.VERSION }}.yml](/opensearch-project/opensearch-build/tree/main/manifests/{{ env.VERSION }}/opensearch-dashboards-{{ env.VERSION }}.yml) with the corresponding checks.
  • OpenSearch / OpenSearch-Dashboards core and components teams finalize their features

Campaigns

REPLACE with OpenSearch wide initiatives to improve quality and consistency.

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/{{ env.VERSION }}/opensearch-{{ env.VERSION }}.yml](/opensearch-project/opensearch-build/tree/main/manifests/{{ env.VERSION }}/opensearch-{{ env.VERSION }}.yml) and [manifests/{{ env.VERSION }}/opensearch-dashboards-{{ env.VERSION }}.yml](/opensearch-project/opensearch-build/tree/main/manifests/{{ env.VERSION }}/opensearch-dashboards-{{ env.VERSION }}.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).
  • 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}

Post Release

  • Create release tags for each component.
  • Replace refs in [manifests/{{ env.VERSION }}](/opensearch-project/opensearch-build/tree/main/manifests/{{ env.VERSION }}) with tags and remove checks.
  • Generate distribution release notes reviewed by PM team for opensearch-build repository.
  • Prepare for next patch release by incrementing patch versions for each component.
  • Lower the frequency of builds for this version of OpenSearch and/or OpenSearch Dashboards.
  • 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 Notes
{COMPONENT_ISSUE_LINK} {INDICATOR}} {STATUS}
Legend

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