Skip to content
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

Update RELEASING.md #184

Merged
merged 5 commits into from
Sep 5, 2024
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
22 changes: 17 additions & 5 deletions RELEASING.md
Original file line number Diff line number Diff line change
Expand Up @@ -8,10 +8,12 @@
- [Incrementing Versions](#incrementing-versions)
- [Tagging](#tagging)
- [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)
- [Release Process](#release-process)
- [OpenSearch Bundle Minor Releases and Patch Releases](#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)
- [OpenSearch Major Releases](#OpenSearch-Major-Releases)
- [Changing Release Date](#Changing-Release-Date)
- [Security Reviews](#security-reviews)
- [Backporting](#backporting)

Expand Down Expand Up @@ -69,15 +71,15 @@ For a discussion on whether to add a prefixing `v` to release tags, see [#35](ht

Repositories create consistent release labels, such as `v2.9.0`, `v1.0.0`, `v1.1.0` and `v2.0.0`, as well as `patch` and `backport`. Use release labels to target an issue or a PR for a given release. See [MAINTAINERS](MAINTAINERS.md#triage-open-issues) for more information on triaging issues.

## Releasing
## Release Process

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
### 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.

Expand All @@ -104,12 +106,22 @@ Please note: This process is for regularly scheduled minor and patch releases.
* All integration tests are passing
* Release blog is ready

### Release Process for OpenSearch Major Releases
### 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).

### Changing Release Date

In the OpenSearch project, we strive for consistent and predictable release schedule as multiple organizations and users depend on the software for their own projects and businesses.
However, sometimes a release date needs to move to accommodate engineering delays in critical components that affect the key properties of the software such as
performance, reliability, availability, or security. In order to move a release date, we will ensure:

* There is a publicly documented justification for moving the release date.
* The justification is circulated 2 weeks or more prior to the original release date.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is posted no later than 2 weeks ...

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we elaborate on documented justification? Is it GitHub issue in specific repo, Slack or something else..

* The organization coordinating the release is in favor of moving the release date.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

might be a nitpick: If the maintainers/release owners are in favor, is that enough? Something about the word "organization" here seems a little funny.

* The leadership committee has voted to move the release date with a simple majority.

### Security Reviews

Expand Down
Loading