From c3c4f19c2eeb75aaff25e7bc7f48586b146d869d Mon Sep 17 00:00:00 2001 From: CEHENKLE Date: Mon, 27 Mar 2023 20:06:53 -0700 Subject: [PATCH 1/9] Intial Version Signed-off-by: CEHENKLE --- RELEASING.md | 46 +++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 45 insertions(+), 1 deletion(-) diff --git a/RELEASING.md b/RELEASING.md index 5afd389f8c1..30896181eb5 100644 --- a/RELEASING.md +++ b/RELEASING.md @@ -68,7 +68,51 @@ Repositories create consistent release labels, such as `v2.9.0`, `v1.0.0`, `v1.1 ## Releasing -See [Releasing OpenSearch](https://github.com/opensearch-project/opensearch-build/blob/main/README.md#releasing-opensearch). +OpenSearch follows semver, which means we will only release breaking changes in major versions. All minor versions are compatible with every other minor version for that major. For example, 1.2.0 will work with 1.3.2, 1.4.1, etc, but may not work with 2.0. + +For minor version releases, OpenSearch uses a “release-train” model. Approximately every six weeks we release a new minor version which includes all the new features and fixes that are ready to go. Having a set release schedule makes sure OpenSearch is releasing in a predictable way and prevents a backlog of unreleased changes. + +In contrast, OpenSearch releases new major versions only when there are a critical mass of breaking changes (e.g. changes that are incompatible with existing APIs). These tend to be tied to Lucene major version releases, and will be announced in the forums at least 4 weeks prior to the release date. + +Please note: Both the roadmap and the release dates reflect intentions rather than firm commitments and may change as we learn more or encounters unexpected issues. If dates do need to change, we will be as transparent as possible, and log all changes in the changelog at the bottom of this page + +### Release Process for Minor Releases + +Summary: +1. OpenSearch runs a release train for minors that starts ~every 6 weeks. Major releases are rare, contain breaking changes, and have their own release process. +1. The start dates for our release windows will be published at the beginning of the year. Any plug-in/component that meets the entrance criteria on the window start date will be picked up for that release. If they aren't ready, we'll version bump the last released version and the release becomes a no-op for them. We will not hold a release for any component. +1. Once the release candidate is generated, we'll enter the "release window". This is a time for final quality testing and polishing documentation as well as performance testing. Bug fixes can go in during this time, but no new features will be added. +1. We will check every day and post on the release issue about the status of the exit criteria. When all the exit criteria have been met for all release components, we'll announce that the candidate is ready, and release it 2 days later (unless that falls on Friday, in which case we'll release on Monday) +1. If we cannot clear the exit criteria within 2 weeks from the start of the window, we will cancel that release window and try again in the next window. + + +At the beginning of every year, the project will publish on [OpenSearch.org](https://opensearch.org/releases.html) the “release windows start” dates for the year. These dates will be spaced out ~6 weeks, and will mark the start of the release window. + +#### Entrance criteria to start release window: +* Documentation draft PRs are up and in tech review for all component changes. +* Sanity testing is done for all components. +* Code coverage is up (all new code has tests). +* Release notes are ready and available for all components. +* Roadmap is up-to-date (information is available to create release highlights). +* Release ticket is cut, and there's a forum post announcing the start of the window. +* [Any necessary security reviews](##Security-Reviews) are complete. + +All components and plugins that are currently released as the OpenSearch bundle will have a chance to join the releases. If a component has not met the entrance criteria by the start of the window, or does not have any changes for that release, we will increment the last released version and add it to the release. + +Once the release candidate has been generated, the project will officially enter the release window for that release. Every day, the release manager will update the release ticket on the status of the release. + +#### Exit criteria to close release window (and make artifacts available): +* Performance tests are run, results are posted to the release ticket and there no unexpected regressions +* Documentation has been fully reviewed and signed off by the documentation community. +* All integration tests are passing +* Release blog is ready + +When all exit criteria have been met, the project will announce the release date -- generally 2 days later, unless that would fall on a Friday or a weekend, in which case we will release on the following Monday. If we cannot meet the exit criteria within 2 weeks of the freeze date, we will skip this minor and release on the next scheduled date. + +### Release Process for Major Releases +OpenSearch releases new major versions only when there are a critical mass of breaking changes (e.g. changes that are incompatible with existing APIs). These tend to be tied to Lucene major version releases, and will be announced in the forums at least 4 weeks prior to the release date. Once we become aware of the need for a major version, we will start a major version release window which will be similar to a minor release, except for two things: Participation is mandatory for all components 2) the window will be at least 4 weeks long to accommodate the testing required. + +For the actual step to build a release, please see [Releasing OpenSearch](https://github.com/opensearch-project/opensearch-build/blob/main/README.md#releasing-opensearch). ### Security Reviews From b448efdf2abe3cc8bb9460acc34456317e49696f Mon Sep 17 00:00:00 2001 From: CEHENKLE Date: Mon, 27 Mar 2023 20:17:57 -0700 Subject: [PATCH 2/9] removed duplicate langauge around majors Signed-off-by: CEHENKLE --- RELEASING.md | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/RELEASING.md b/RELEASING.md index 30896181eb5..e446d10832d 100644 --- a/RELEASING.md +++ b/RELEASING.md @@ -74,8 +74,6 @@ For minor version releases, OpenSearch uses a “release-train” model. Approxi In contrast, OpenSearch releases new major versions only when there are a critical mass of breaking changes (e.g. changes that are incompatible with existing APIs). These tend to be tied to Lucene major version releases, and will be announced in the forums at least 4 weeks prior to the release date. -Please note: Both the roadmap and the release dates reflect intentions rather than firm commitments and may change as we learn more or encounters unexpected issues. If dates do need to change, we will be as transparent as possible, and log all changes in the changelog at the bottom of this page - ### Release Process for Minor Releases Summary: @@ -110,7 +108,7 @@ Once the release candidate has been generated, the project will officially enter When all exit criteria have been met, the project will announce the release date -- generally 2 days later, unless that would fall on a Friday or a weekend, in which case we will release on the following Monday. If we cannot meet the exit criteria within 2 weeks of the freeze date, we will skip this minor and release on the next scheduled date. ### Release Process for Major Releases -OpenSearch releases new major versions only when there are a critical mass of breaking changes (e.g. changes that are incompatible with existing APIs). These tend to be tied to Lucene major version releases, and will be announced in the forums at least 4 weeks prior to the release date. Once we become aware of the need for a major version, we will start a major version release window which will be similar to a minor release, except for two things: Participation is mandatory for all components 2) the window will be at least 4 weeks long to accommodate the testing required. +OpenSearch only does major releases when there are significant breaking changes that are ready for release. Once we become aware of the need for a major version, we will start a major version release window which will be similar to a minor release, except for two things: Participation is mandatory for all components and the release window will be at least 4 weeks long to accommodate the testing required. For the actual step to build a release, please see [Releasing OpenSearch](https://github.com/opensearch-project/opensearch-build/blob/main/README.md#releasing-opensearch). From 13ecef171bbce8fc10dee7ea7bbe08cf92c7fda0 Mon Sep 17 00:00:00 2001 From: CEHENKLE Date: Tue, 28 Mar 2023 20:23:04 -0700 Subject: [PATCH 3/9] Added Major Release, removed duplicate language Signed-off-by: CEHENKLE --- RELEASING.md | 31 +++++++++++++------------------ 1 file changed, 13 insertions(+), 18 deletions(-) diff --git a/RELEASING.md b/RELEASING.md index e446d10832d..d30cabedf82 100644 --- a/RELEASING.md +++ b/RELEASING.md @@ -70,47 +70,42 @@ Repositories create consistent release labels, such as `v2.9.0`, `v1.0.0`, `v1.1 OpenSearch follows semver, which means we will only release breaking changes in major versions. All minor versions are compatible with every other minor version for that major. For example, 1.2.0 will work with 1.3.2, 1.4.1, etc, but may not work with 2.0. -For minor version releases, OpenSearch uses a “release-train” model. Approximately every six weeks we release a new minor version which includes all the new features and fixes that are ready to go. Having a set release schedule makes sure OpenSearch is releasing in a predictable way and prevents a backlog of unreleased changes. +OpenSearch uses a “release-train” model. For minor version, that train leaves approximately every six weeks we release a new minor version which includes all the new features and fixes that are ready to go. Having a set release schedule makes sure OpenSearch is releasing in a predictable way and prevents a backlog of unreleased changes. In contrast, OpenSearch releases new major versions only when there are a critical mass of breaking changes (e.g. changes that are incompatible with existing APIs). These tend to be tied to Lucene major version releases, and will be announced in the forums at least 4 weeks prior to the release date. -### Release Process for Minor Releases - -Summary: -1. OpenSearch runs a release train for minors that starts ~every 6 weeks. Major releases are rare, contain breaking changes, and have their own release process. -1. The start dates for our release windows will be published at the beginning of the year. Any plug-in/component that meets the entrance criteria on the window start date will be picked up for that release. If they aren't ready, we'll version bump the last released version and the release becomes a no-op for them. We will not hold a release for any component. -1. Once the release candidate is generated, we'll enter the "release window". This is a time for final quality testing and polishing documentation as well as performance testing. Bug fixes can go in during this time, but no new features will be added. -1. We will check every day and post on the release issue about the status of the exit criteria. When all the exit criteria have been met for all release components, we'll announce that the candidate is ready, and release it 2 days later (unless that falls on Friday, in which case we'll release on Monday) -1. If we cannot clear the exit criteria within 2 weeks from the start of the window, we will cancel that release window and try again in the next window. +### Release Process for OpenSearch Bundle Minor Releases +At the beginning of every year, the project will publish on [OpenSearch.org](https://opensearch.org/releases.html) the “release windows start” dates for the year. These dates will be spaced out ~6 weeks. -At the beginning of every year, the project will publish on [OpenSearch.org](https://opensearch.org/releases.html) the “release windows start” dates for the year. These dates will be spaced out ~6 weeks, and will mark the start of the release window. +On release window start date: +1. We generate the first candidate with all plug-ins/components that have met the entrance criteria. If a plug-in/component hasn't met all of the criteria, we'll version bump the last released version and release that. Once the release window opens and the first candidate is generated, no additioanl features can be added, and we will not delay the start of a release window for any plug-in/component. +1. During the release window we will do final quality testing, documentation and performance testing. Bug fixes can be added in during this time, but no new features will be added. +1. We will generate a new candidate every day and post on the release issue about the status of the exit criteria. When all the exit criteria have been met, we'll announce that the candidate is ready and release it 2 days later (unless that falls on Friday, in which case we'll release on Monday) +1. If we cannot clear the exit criteria within 2 weeks from the start of the window, we will cancel that release window and try again in the next window. #### Entrance criteria to start release window: * Documentation draft PRs are up and in tech review for all component changes. * Sanity testing is done for all components. -* Code coverage is up (all new code has tests). +* Code coverage has not decreased (all new code has tests). * Release notes are ready and available for all components. * Roadmap is up-to-date (information is available to create release highlights). * Release ticket is cut, and there's a forum post announcing the start of the window. * [Any necessary security reviews](##Security-Reviews) are complete. -All components and plugins that are currently released as the OpenSearch bundle will have a chance to join the releases. If a component has not met the entrance criteria by the start of the window, or does not have any changes for that release, we will increment the last released version and add it to the release. - -Once the release candidate has been generated, the project will officially enter the release window for that release. Every day, the release manager will update the release ticket on the status of the release. - #### Exit criteria to close release window (and make artifacts available): * Performance tests are run, results are posted to the release ticket and there no unexpected regressions * Documentation has been fully reviewed and signed off by the documentation community. * All integration tests are passing * Release blog is ready -When all exit criteria have been met, the project will announce the release date -- generally 2 days later, unless that would fall on a Friday or a weekend, in which case we will release on the following Monday. If we cannot meet the exit criteria within 2 weeks of the freeze date, we will skip this minor and release on the next scheduled date. +### Release Process for OpenSearch Bundle Major Releases -### Release Process for Major Releases OpenSearch only does major releases when there are significant breaking changes that are ready for release. Once we become aware of the need for a major version, we will start a major version release window which will be similar to a minor release, except for two things: Participation is mandatory for all components and the release window will be at least 4 weeks long to accommodate the testing required. -For the actual step to build a release, please see [Releasing OpenSearch](https://github.com/opensearch-project/opensearch-build/blob/main/README.md#releasing-opensearch). +For the actual steps to build a release, please see [Releasing OpenSearch](https://github.com/opensearch-project/opensearch-build/blob/main/README.md#releasing-opensearch). + +### Release Process for non-bundled OpenSearch ### Security Reviews From e9a8d8b4513bee38267f8e1a44f724727fabea95 Mon Sep 17 00:00:00 2001 From: CEHENKLE Date: Tue, 15 Aug 2023 10:59:26 -0700 Subject: [PATCH 4/9] cleaned up TOC, added patch release info Signed-off-by: CEHENKLE --- RELEASING.md | 14 +++++++++----- 1 file changed, 9 insertions(+), 5 deletions(-) diff --git a/RELEASING.md b/RELEASING.md index d30cabedf82..a2bd06688be 100644 --- a/RELEASING.md +++ b/RELEASING.md @@ -9,7 +9,10 @@ - [Tagging](#tagging) - [Release Labels](#release-labels) - [Releasing](#releasing) - - [Security Reviews](#security-reviews) + - [Release Process for OpenSearch Bundle Minor Releases and Patch Releases](#Release-Process-for-OpenSearch-Bundle-Minor-Releases-and-Patch-Releases) + - [Entrance criteria to start release window](Entrance-criteria-to-start-release-window) + - [Exit criteria to close release window \(and make artifacts available\)](#Exit-criteria-to-close-release-window-(and-make-artifacts-available)) +- [Security Reviews](#security-reviews) - [Backporting](#backporting) ## Overview @@ -74,7 +77,7 @@ OpenSearch uses a “release-train” model. For minor version, that train leave In contrast, OpenSearch releases new major versions only when there are a critical mass of breaking changes (e.g. changes that are incompatible with existing APIs). These tend to be tied to Lucene major version releases, and will be announced in the forums at least 4 weeks prior to the release date. -### Release Process for OpenSearch Bundle Minor Releases +### Release Process for OpenSearch Bundle Minor Releases and Patch Releases At the beginning of every year, the project will publish on [OpenSearch.org](https://opensearch.org/releases.html) the “release windows start” dates for the year. These dates will be spaced out ~6 weeks. @@ -82,7 +85,9 @@ On release window start date: 1. We generate the first candidate with all plug-ins/components that have met the entrance criteria. If a plug-in/component hasn't met all of the criteria, we'll version bump the last released version and release that. Once the release window opens and the first candidate is generated, no additioanl features can be added, and we will not delay the start of a release window for any plug-in/component. 1. During the release window we will do final quality testing, documentation and performance testing. Bug fixes can be added in during this time, but no new features will be added. 1. We will generate a new candidate every day and post on the release issue about the status of the exit criteria. When all the exit criteria have been met, we'll announce that the candidate is ready and release it 2 days later (unless that falls on Friday, in which case we'll release on Monday) -1. If we cannot clear the exit criteria within 2 weeks from the start of the window, we will cancel that release window and try again in the next window. +1. If we cannot clear the exit criteria within 2 weeks from the start of the window (1 week for patch releases), we will cancel that release window and try again in the next window. + +Please note: This process is for regularly scheduled minor and patch releases. For "hot" patches (patches required for security or other urgent issues) we will build, test and release as quickly as possible. #### Entrance criteria to start release window: * Documentation draft PRs are up and in tech review for all component changes. @@ -99,13 +104,12 @@ On release window start date: * All integration tests are passing * Release blog is ready -### Release Process for OpenSearch Bundle Major Releases +### Release Process for OpenSearch Major Releases OpenSearch only does major releases when there are significant breaking changes that are ready for release. Once we become aware of the need for a major version, we will start a major version release window which will be similar to a minor release, except for two things: Participation is mandatory for all components and the release window will be at least 4 weeks long to accommodate the testing required. For the actual steps to build a release, please see [Releasing OpenSearch](https://github.com/opensearch-project/opensearch-build/blob/main/README.md#releasing-opensearch). -### Release Process for non-bundled OpenSearch ### Security Reviews From 25b04c05a062b2e520696dc1fc9a43d01259db02 Mon Sep 17 00:00:00 2001 From: CEHENKLE Date: Tue, 15 Aug 2023 11:09:42 -0700 Subject: [PATCH 5/9] Fixing TOC Signed-off-by: CEHENKLE --- RELEASING.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/RELEASING.md b/RELEASING.md index a2bd06688be..b66db0f81d8 100644 --- a/RELEASING.md +++ b/RELEASING.md @@ -10,7 +10,7 @@ - [Release Labels](#release-labels) - [Releasing](#releasing) - [Release Process for OpenSearch Bundle Minor Releases and Patch Releases](#Release-Process-for-OpenSearch-Bundle-Minor-Releases-and-Patch-Releases) - - [Entrance criteria to start release window](Entrance-criteria-to-start-release-window) + - [Entrance criteria to start release window](#Entrance-criteria-to-start-release-window) - [Exit criteria to close release window \(and make artifacts available\)](#Exit-criteria-to-close-release-window-(and-make-artifacts-available)) - [Security Reviews](#security-reviews) - [Backporting](#backporting) @@ -89,7 +89,7 @@ On release window start date: Please note: This process is for regularly scheduled minor and patch releases. For "hot" patches (patches required for security or other urgent issues) we will build, test and release as quickly as possible. -#### Entrance criteria to start release window: +#### Entrance criteria to start release window * Documentation draft PRs are up and in tech review for all component changes. * Sanity testing is done for all components. * Code coverage has not decreased (all new code has tests). @@ -98,7 +98,7 @@ Please note: This process is for regularly scheduled minor and patch releases. * Release ticket is cut, and there's a forum post announcing the start of the window. * [Any necessary security reviews](##Security-Reviews) are complete. -#### Exit criteria to close release window (and make artifacts available): +#### Exit criteria to close release window (and make artifacts available) * Performance tests are run, results are posted to the release ticket and there no unexpected regressions * Documentation has been fully reviewed and signed off by the documentation community. * All integration tests are passing From 388dcc8264b15128bbe34c6e2fe481847d5eb3d5 Mon Sep 17 00:00:00 2001 From: CEHENKLE Date: Tue, 15 Aug 2023 11:14:07 -0700 Subject: [PATCH 6/9] one last escape Signed-off-by: CEHENKLE --- RELEASING.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/RELEASING.md b/RELEASING.md index b66db0f81d8..f55f1d93d42 100644 --- a/RELEASING.md +++ b/RELEASING.md @@ -11,7 +11,7 @@ - [Releasing](#releasing) - [Release Process for OpenSearch Bundle Minor Releases and Patch Releases](#Release-Process-for-OpenSearch-Bundle-Minor-Releases-and-Patch-Releases) - [Entrance criteria to start release window](#Entrance-criteria-to-start-release-window) - - [Exit criteria to close release window \(and make artifacts available\)](#Exit-criteria-to-close-release-window-(and-make-artifacts-available)) + - [Exit criteria to close release window \(and make artifacts available\)](#Exit-criteria-to-close-release-window-\(and-make-artifacts-available\)) - [Security Reviews](#security-reviews) - [Backporting](#backporting) From fe381062cb3f424b7257baa1da6a4f1cfaeb3320 Mon Sep 17 00:00:00 2001 From: CEHENKLE Date: Tue, 15 Aug 2023 11:30:37 -0700 Subject: [PATCH 7/9] did a DB special (removed words) Signed-off-by: CEHENKLE --- RELEASING.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/RELEASING.md b/RELEASING.md index f55f1d93d42..55d66c8cb67 100644 --- a/RELEASING.md +++ b/RELEASING.md @@ -11,7 +11,7 @@ - [Releasing](#releasing) - [Release Process for OpenSearch Bundle Minor Releases and Patch Releases](#Release-Process-for-OpenSearch-Bundle-Minor-Releases-and-Patch-Releases) - [Entrance criteria to start release window](#Entrance-criteria-to-start-release-window) - - [Exit criteria to close release window \(and make artifacts available\)](#Exit-criteria-to-close-release-window-\(and-make-artifacts-available\)) + - [Exit criteria to close release window](#Exit-criteria-to-close-release-window)) - [Security Reviews](#security-reviews) - [Backporting](#backporting) @@ -98,7 +98,7 @@ Please note: This process is for regularly scheduled minor and patch releases. * Release ticket is cut, and there's a forum post announcing the start of the window. * [Any necessary security reviews](##Security-Reviews) are complete. -#### Exit criteria to close release window (and make artifacts available) +#### Exit criteria to close release window * Performance tests are run, results are posted to the release ticket and there no unexpected regressions * Documentation has been fully reviewed and signed off by the documentation community. * All integration tests are passing From 50a29946f702fd99e26bbe66aeb5744d543265d7 Mon Sep 17 00:00:00 2001 From: CEHENKLE Date: Tue, 15 Aug 2023 11:33:19 -0700 Subject: [PATCH 8/9] removed ) Signed-off-by: CEHENKLE --- RELEASING.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/RELEASING.md b/RELEASING.md index 55d66c8cb67..cffefdb075f 100644 --- a/RELEASING.md +++ b/RELEASING.md @@ -11,7 +11,7 @@ - [Releasing](#releasing) - [Release Process for OpenSearch Bundle Minor Releases and Patch Releases](#Release-Process-for-OpenSearch-Bundle-Minor-Releases-and-Patch-Releases) - [Entrance criteria to start release window](#Entrance-criteria-to-start-release-window) - - [Exit criteria to close release window](#Exit-criteria-to-close-release-window)) + - [Exit criteria to close release window](#Exit-criteria-to-close-release-window) - [Security Reviews](#security-reviews) - [Backporting](#backporting) From 3271d7073be06b5a71d93b991812108dec6a0b74 Mon Sep 17 00:00:00 2001 From: CEHENKLE Date: Wed, 16 Aug 2023 10:55:37 -0700 Subject: [PATCH 9/9] upper casing title Signed-off-by: CEHENKLE --- RELEASING.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/RELEASING.md b/RELEASING.md index cffefdb075f..27b4d7ba84f 100644 --- a/RELEASING.md +++ b/RELEASING.md @@ -10,8 +10,8 @@ - [Release Labels](#release-labels) - [Releasing](#releasing) - [Release Process for OpenSearch Bundle Minor Releases and Patch Releases](#Release-Process-for-OpenSearch-Bundle-Minor-Releases-and-Patch-Releases) - - [Entrance criteria to start release window](#Entrance-criteria-to-start-release-window) - - [Exit criteria to close release window](#Exit-criteria-to-close-release-window) + - [Entrance Criteria to Start Release Window](#Entrance-Criteria-to-Start-Release-Window) + - [Exit Criteria to Close Release Window](#Exit-Criteria-to-Close-Release-Window) - [Security Reviews](#security-reviews) - [Backporting](#backporting) @@ -89,7 +89,7 @@ On release window start date: Please note: This process is for regularly scheduled minor and patch releases. For "hot" patches (patches required for security or other urgent issues) we will build, test and release as quickly as possible. -#### Entrance criteria to start release window +#### Entrance Criteria to Start Release Window * Documentation draft PRs are up and in tech review for all component changes. * Sanity testing is done for all components. * Code coverage has not decreased (all new code has tests). @@ -98,7 +98,7 @@ Please note: This process is for regularly scheduled minor and patch releases. * Release ticket is cut, and there's a forum post announcing the start of the window. * [Any necessary security reviews](##Security-Reviews) are complete. -#### Exit criteria to close release window +#### Exit Criteria to Close Release Window * Performance tests are run, results are posted to the release ticket and there no unexpected regressions * Documentation has been fully reviewed and signed off by the documentation community. * All integration tests are passing