Add minor and patch release information. #227
Conversation
dblock
requested review from
CEHENKLE,
mch2,
peternied and
saratvemulapalli
as code owners
dblock
force-pushed
the
clarify-releases
branch
from
27fbd7f
to
e49dd79
Compare
|
|
||
| [OpenSearch](https://github.com/opensearch-project/OpenSearch) typically tracks 3 releases in parallel. For example, given the last major release of 2.0, OpenSearch in this organization maintains the following active branches. | ||
| Most repos in this organization, including [OpenSearch](https://github.com/opensearch-project/OpenSearch) and [OpenSearch-Dashboards](https://github.com/opensearch-project/OpenSearch-Dashboards), typically track 3 releases in parallel. For example, given the last major release of 2.0, OpenSearch and all its components in this organization maintains the following active branches. | ||
|
|
||
| * **main**: The _next major_ release, currently 3.0. This is the branch where all merges take place, and code moves fast. | ||
| * * **2.x**: The _next minor_ release. Once a change is merged into `main`, decide whether to backport it to `2.x`. |
There was a problem hiding this comment.
where is the branch for next patch release? could we add that, i would suggest to use 2.0.x
There was a problem hiding this comment.
I added
* * **2.17**: The _last minor_ release and the _next patch_ release. Once a change is merged into `2.x`, it may be backported to, for example, `2.17` for the next 2.17 release candidate, or as a patch for a `2.12.1`.
There was a problem hiding this comment.
-
- 2.x: The next minor release
2.17for the next 2.17 release candidate, or as a patch for a2.12.1.
- 2.x: The next minor release
what's the different between next minor releae compare to release candidate?
if 2.x if for next minor release, why could we add 2.17.x for next patch release, then we should use 2.17.1 for release candidate
i know opensearch is using 2.17.1 for tag. but it is not very common compare to other opensource project.
There was a problem hiding this comment.
On 2.x you usually have the next minor release. Then eventually we cut 2.17 and make last minute fixes there to make the 2.17 release. So they are the same thing.
Then we make patches on top of 2.17 in the 2.17 branch while 2.x will have moved to 2.18. And release 2.17.1 from 2.17 branch.
Suggest a change if that's not clear from my text?
|
|
||
| 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. | ||
| We follow [OpenSSF's best practices](https://bestpractices.coreinfrastructure.org/en/criteria/0?details=true&rationale=true#0.vulnerabilities_fixed_60_days) for patching publicly known vulnerabilities and we make sure that there are no unpatched vulnerabilities of medium or higher severity that have been publicly known for more than 60 days in our actively maintained versions. |
There was a problem hiding this comment.
For OSD 1.3.x is still Node 10 , its lifecycle Ended 3 years and 4 months ago. we need a better version strategy and lifecycle management for long term support. in the case. i would suggest to decouple OpenSearch Dashboards and OpenSearch release. and we could end support to OSD 1.3 because it is not secure, and we could not upgrade without break.
There was a problem hiding this comment.
Anything that this PR needs changing?
There was a problem hiding this comment.
| We follow [OpenSSF's best practices](https://bestpractices.coreinfrastructure.org/en/criteria/0?details=true&rationale=true#0.vulnerabilities_fixed_60_days) for patching publicly known vulnerabilities and we make sure that there are no unpatched vulnerabilities of medium or higher severity that have been publicly known for more than 60 days in our actively maintained versions. | |
| We follow [OpenSSF's best practices](https://bestpractices.coreinfrastructure.org/en/criteria/0?details=true&rationale=true#0.vulnerabilities_fixed_60_days) for patching publicly known vulnerabilities and we make sure that there are no unpatched vulnerabilities of medium or higher severity that have been publicly known for more than 60 days in our actively maintained versions. | |
| Please note: The runtime for OpenSearch Dashboards 1.3.x is based on Node.js 10, which has been end-of-life (EOL) for 3 years. Due to this, critical bug fixes and security patches are handled on a best-effort basis, as upgrading Node.js for 1.3.x would introduce significant breaking changes. This limitation arises from the need to release OpenSearch and OpenSearch Dashboards together. | |
| We are aware of this issue and have a roadmap item to decouple the releases and versions for OpenSearch and OpenSearch Dashboards. This will allow us to upgrade or manage the versions of OpenSearch Dashboards independently in the future. More details can be found in the [OpenSearch Project Roadmap for 2024–2025](https://opensearch.org/blog/opensearch-project-roadmap-2024-2025/#roadmap-theme-3-ease-of-use) section: Serverless Dashboards and migration. |
There was a problem hiding this comment.
This is way too specific for this doc. What's the GitHub issue that captures this detail?
I could change "we follow" to "Except for well-documented exceptions such as xyz, we follow ...".
There was a problem hiding this comment.
I linked roadmap, a github issue might not necessary, if words is too much, we keep it short? there are two keypoints here, first is security patch is best effort for previous major version (1.x or what term we name it, please help). second it doesn't scale if we bump whole bundle distribution if only one component need to bump. decoupling project and make them release-able independently is roadmap.
There was a problem hiding this comment.
The problem is that I have to put words here that explain what we're trying to do to fix this problem, so this is not the right place. There should be a single GH issue that describes the problem (node.js version is deprecated but still used) and then people can go understand how the roadmap fixes that problem from there. Help me find the issue?
|
|
||
| #### Release Process | ||
|
|
||
| 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. |
There was a problem hiding this comment.
we did 6 minor version release in 2023, planed 6 minor in 2024, so it is about every 8 weeks right.
There was a problem hiding this comment.
@getsaurabh02 is this correct?
RELEASING.md
Outdated
|
|
||
| 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. | ||
| 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 additional features can be added, and we will not delay the start of a release window for any plug-in/component. | ||
| 2. 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. |
There was a problem hiding this comment.
what's the different between final quality test and test we enforce for each commit/PR
There was a problem hiding this comment.
| 2. 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. | |
| 2. During the release window, we will conduct final quality testing, documentation updates, and performance testing. Bug fixes can be added during this time, but no new features will be included. We are not yet able to run release testing against every commit of each repository. During the release process, we will only enforce that each component addresses failed tests by either fixing them or skipping flaky tests. Neither the 2.x nor the 2.17 branches will meet the release quality bar without going through the full release process, including testing. In the case that any third party wants to fork and release from the 2.x or 2.17 branches, they will need to ensure they run their own quality tests at their own risk. |
There was a problem hiding this comment.
I think this is confusing, at least in the release window section because it talks about state of a 2.x branch. I'll think about where to incorporate it, but for now not adding.
|
hi repo/org admin
|
Yes it is, why? This repo follows the same maintainer model as for all other repos. These folks have contributed to it. |
dblock
force-pushed
the
clarify-releases
branch
from
e49dd79
to
b3aaaea
Compare
|
I think this can be merged as is, wdyt @peternied @CEHENKLE? |
|
|
||
| For a discussion on whether to add a prefixing `v` to release tags, see [#35](https://github.com/opensearch-project/.github/issues/35). | ||
| For example, the OpenSearch bundle that contains OpenSearch and OpenSearch Dashboards releases new major versions after Lucene major version releases. This is 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 start a major version release window which is similar to a minor release, except for two things: 1) participation is mandatory for all components, and 2) the release window is at least 4 weeks long to accommodate the testing required. |
There was a problem hiding this comment.
So whaddya do if a component doesn't participate? Drop it? With some components down to a few maintainers, this is a going concern.
There was a problem hiding this comment.
The release team picks it up.
peternied
force-pushed
the
clarify-releases
branch
from
1e2c605
to
6c5441d
Compare
Signed-off-by: dblock <[email protected]>
…rsion into an example. Signed-off-by: dblock <[email protected]>
Signed-off-by: dblock <[email protected]>
Signed-off-by: dblock <[email protected]>
Signed-off-by: dblock <[email protected]>
Signed-off-by: dblock <[email protected]>
dblock
force-pushed
the
clarify-releases
branch
from
6c5441d
to
423c00a
Compare
|
@peternied I rebased. |
|
@seraphjiang There are a couple of outstanding threads from feedback you created, did you want to take another look while these changes bake? |
|
@CEHENKLE @getsaurabh02 We are waiting on a second approval, what do you think about merging this change? |
Description
Did a pass on RELEASING. We have some information in https://opensearch.org/releases.html such as the fact that we follow OpenSSF patch criteria, and don't explicitly mention minor and patch releases containing features/fixes/security patches.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.