-
Notifications
You must be signed in to change notification settings - Fork 70
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Proposed changes to minor release process #151
Changes from 8 commits
c3c4f19
b448efd
13ecef1
e9a8d8b
25b04c0
388dcc8
fe38106
50a2994
3271d70
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -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](#Exit-criteria-to-close-release-window) | ||
- [Security Reviews](#security-reviews) | ||
- [Backporting](#backporting) | ||
|
||
## Overview | ||
|
@@ -68,7 +71,45 @@ 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. | ||
|
||
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 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. | ||
|
||
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 (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 | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This language doesn't 'flow' for me. I don't start a 'time box', I start a doing a completable task or abort when out of time. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Did you mean to highlight this section? If so, do you have a language suggestion? Thanks! There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This was the right section, but I don't have a suggestion - if it works for you lets keep it. I can always make a PR if I come up with something clever |
||
* Documentation draft PRs are up and in tech review for all component changes. | ||
* Sanity testing is done for all components. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @CEHENKLE What is sanity testing? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I can answer this. Sometimes we do have humans clicking some buttons and call it "sanity testing" :) There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yup. db is correct. It's very basic "please make sure everything looks sane to a human in case anything is missed by automated testing" testing. |
||
* 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. | ||
|
||
#### 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 | ||
* Release blog is ready | ||
|
||
### 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). | ||
|
||
|
||
### Security Reviews | ||
|
||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will the candidate be deployed somewhere publicly on a playground?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've opened an issue to request the the nightly build get deployed to playground: https://github.com/opensearch-project/opensearch-build/issues/3881
But we generally put up the RC builds, even if they're not on playground.
Feel free to add to the issue