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.

Sign up for GitHub

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

Jump to bottom

Add OpenSearch status report #189

Closed
wants to merge 6 commits into from
Closed

Add OpenSearch status report #189

Changes from 3 commits
Commits
Show all changes
6 commits
Select commit Hold shift + click to select a range
f7b00d8
Add OpenSearch status report
smortex Jun 17, 2023
7bd2c1a
One sentense per line
smortex Jun 17, 2023
b4286c4
Fix typos
smortex Jun 17, 2023
a8995dc
Proofread
smortex Jun 18, 2023
c5fad1a
Update latest opensearch release
smortex Jul 3, 2023
b9bc7e5
Use the package macro to reference pacakages
smortex Jul 3, 2023
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
21 changes: 21 additions & 0 deletions website/content/en/status/report-2023-04-2023-06/opensearch.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,21 @@
=== OpenSearch

Links: +
link:https://opensearch.org/[OpenSearch] URL: link:https://opensearch.org/[] +

Contact: OpenSearch Team <[email protected]>

OpenSearch is a community-driven, open-source search and analytics suite derived from Apache 2.0 licensed ElasticSearch 7.10.2 & Kibana 7.10.2.
It consists of a search engine daemon, OpenSearch, and a visualization and user interface, OpenSearch Dashboards.
OpenSearch enables people to easily ingest, secure, search, aggregate, view, and analyze data.
These capabilities are popular for use cases such as application search, log analytics, and more.
With OpenSearch people benefit from having an open-source product they can use, modify, extend, monetize, and resell as they want.

Since our last status report, the OpenSearch Team has regularly updated the OpenSearch and OpenSearch-Dashboards ports to follow upstream releases.

While minor version updates are generally straightforward, some use cases make this slightly harder and require more work.
For this reason, the OpenSearch Team has recently decided to change the way we package OpenSearch.
Instead of our current scheme where we provide 2 ports, one for the latest major version (`textproc/openseach`, currently at version 2.7.0) and one for the legacy major version in maintenance mode(`textproc/openseach13`, currently at version 1.3.10), we will move to distribute each minor version as a new port (i.e. `textproc/openseach26`, `textproc/openseach27`, `textproc/openseach28` and so on).
smortex marked this conversation as resolved.
Show resolved Hide resolved

Because upstream only provides updates for the latest major version, when a new minor version is made available and a new port is added, the previous minor version will be marked as deprecated, and the minor version before that will have an expiration date set, and will be removed at least three months later.
Copy link
Contributor

Choose a reason for hiding this comment

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

Do you mean "only provides updates for the latest minor version" here?

Copy link
Member Author

@smortex smortex Jun 18, 2023 •
edited
Loading

Choose a reason for hiding this comment

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

Hum, I don't think so. But this is ambiguous…

Let me describe this with an actual example:

As of today, 1.3.10 is the last 1.x major version, and is in maintenance mode, so the next versions will be 1.3.11, 1.3.12, etc and no 1.4.0 will ever be released.

2.8.0 is the last 2.x major version. The next version should be 2.9.0, but if some critical security issue is found, a 2.8.1 can be released quickly to just fix the security issue. Then 2.9.0 will follow according to the initial schedule (unless a new critical security issue is found and fixed in 2.8.2). Once 2.9.0 is released, no more 2.8.x will be released.

I tried to rephrase the sentence but it still seems very convoluted. English not being a native language, I guess it does not help me 😄 But I hope it can help to iterate!

Suggested change
Because upstream only provides updates for the latest major version, when a new minor version is made available and a new port is added, the previous minor version will be marked as deprecated, and the minor version before that will have an expiration date set, and will be removed at least three months later.
Upstream ship new OpenSearch releases according to a public schedule.
Only the latest release of each major version is supported.
In case a critical security issue is found, it will be patched in a new patch release of that latest release of the affected major versions.
In order to ease migration, when a new minor version of OpenSearch is released and a new port is added, the port of the previous minor version will be marked deprecated, and the port of the second-to-previous minor version will have an expired date set to 3 months later.

Copy link
Contributor

Choose a reason for hiding this comment

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

As of today, 1.3.10 is the last 1.x major version, and is in maintenance mode, so the next versions will be 1.3.11, 1.3.12, etc and no 1.4.0 will ever be released.

2.8.0 is the last 2.x major version. The next version should be 2.9.0, but if some critical security issue is found, a 2.8.1 can be released quickly to just fix the security issue. Then 2.9.0 will follow according to the initial schedule (unless a new critical security issue is found and fixed in 2.8.2). Once 2.9.0 is released, no more 2.8.x will be released.

OK, this sounds like the OpenSearch major version IDs have two components (1.3 or 2.8), not just one (1 or 2) as I thought. Is that correct?

Copy link
Member Author

Choose a reason for hiding this comment

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

They are supposed to follow semver, so I think it makes more sense to stick to the semver MAJOR.MINOR.PATCH scheme.

MAJOR version 1 is in maintenance "mode", so no new feature will get in and the MINOR component will not change, only new PATCH release will happen.

MAJOR version 2 is the current branch where new features get in and MINOR is likely to be bumped when new releases are made. We should generally see MAJOR.MINOR.0, MAJOR.MINOR.1 can happen but is unlikely while version 2 is the current one.

When version 3 will be released, version 2 will switch to maintenance mode where the PATCH component of the latest 2.MINOR.PATCH will be increased and MINOR will stay the same because no new features will come in, only bugfixes.

Users are advised to use the latest minor version, but this will not happen automatically and provides a grace period for users running software that needs to be updated accordingly.