-
Notifications
You must be signed in to change notification settings - Fork 324
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
Add OpenSearch status report #189
Changes from all commits
f7b00d8
7bd2c1a
b4286c4
a8995dc
c5fad1a
b9bc7e5
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 |
---|---|---|
@@ -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 (package:textproc/opensearch[], currently at version 2.8.0) and one for the legacy major version in maintenance mode(package:textproc/opensearch13[], currently at version 1.3.10), we will move to distribute each minor version as a new port (i.e. package:textproc/opensearch26[], package:textproc/opensearch27[], package:textproc/opensearch28[] and so on). | ||
|
||
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. | ||
Comment on lines
+16
to
+20
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. @alonsobsd reading opensearch-freebsd/freebsd-ports#1 (comment) I understand that this is not really necessary anymore and we can stick with the current scheme unless AWS does 💩 and then we would handle this with a new version-specific port? If so, this whole PR does not have much to say to our users, and I think we can dismiss it. What do you think? |
||
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. |
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.
Do you mean "only provides updates for the latest minor version" here?
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.
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 be1.3.11
,1.3.12
, etc and no1.4.0
will ever be released.2.8.0
is the last 2.x major version. The next version should be2.9.0
, but if some critical security issue is found, a2.8.1
can be released quickly to just fix the security issue. Then2.9.0
will follow according to the initial schedule (unless a new critical security issue is found and fixed in2.8.2
). Once2.9.0
is released, no more2.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!
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.
OK, this sounds like the OpenSearch major version IDs have two components (
1.3
or2.8
), not just one (1
or2
) as I thought. Is that correct?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.
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.