-
Notifications
You must be signed in to change notification settings - Fork 0
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
textproc/opensearch: Update to 2.8.0 #1
Conversation
With hat: opensearch
With hat: opensearch
I think we can not follow the same release model like opensearch because it could break easily some ports like wazuh for example. Probably 2.7.1 will be released in some moment. Perphaps the best could be add devel ports for update it with latest version of opensearch? (opensearch-devel, opensearch-dashboards-devel) or just add a specific version for wazuh for example (opensearch26, opensearch26-dashboards)? what do you think about it? |
Hum… https://opensearch.org/blog/what-is-semver/ made me think this should not happen (2.7.1), but maybe I am wrong. I'll ask the question on Slack and add a link here so that maybe someone can help us. |
Got confirmation form someone from AWS/OpenSearch that after 2.8.0, the next version will be 2.8.1 or 2.9.0 but there will be no more 2.7.x or any older 2.x version. They do releases for the two maintained branches: 1.x and 2.x, and releases are cut from these. That being said, if it helps with your use case, we can create a different port for each minor version, knowing that it will not be updated once a newer minor version is released, so at that point we can mark the port textproc/opensearch26 (2.6.0, DEPRECATED) We can also have textproc/opensearch for the lastest version, and when a new minor version is made available copy it and then update: textproc/opensearch26 (2.6.0, DEPRECATED) becomes when 2.9.0 is released: textproc/opensearch26 (2.6.0, DEPRECATED) |
'd agree on splitting Ports into versions. I think the same goes for Wazuh, etc.? I think using flavors would be a good option. For example, a meta port For pkg.FreeBSD.org, you will always get the latest version. If you need to stick to a specific version (e.g., Wazuh not being up to date), you can either install the specific release or configure your branch in pourdriere/make.conf (DEFAULT_VERSIONS). The advantage would be the you don't need to touch any automation templates/workflows. |
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.
No issues after upgrade from 2.4 and 2.6
The only reason we release something like 2.7.1 would be a critical (high?) security vulnerability that cannot wait for a 2.8.0. We should clarify this in OpenSearch docs, too, please feel free to open an issue/contribute. |
@dblock 2.8.0 is currently available 😅 … Did you mean:
|
Got confirmation from slack. If today (latest versions of OS are 1.3.10 and 2.8.0) a critical vulnerability is found, it would be fixed as 1.3.11 and 2.8.1 in a timely fashion. So this proposition is right:
And to complete this, if a non-critical vulnerability is found, the fix will be part of the next release, 2.9.0, according to the schedule for that release (July 18th, 2023 for 2.9.0 according to the OpenSearch Project Roadmap). |
Right on. Want to contribute this explanation to https://github.com/opensearch-project/OpenSearch-build#releases-and-versions? This way the FreeBSD port can reference it? |
@dblock That would be great! I though I could do this before going on holiday but I still have to pack the things 😓 I'll try to give it a shot when I am back after next week. Regarding the change in the way we manage the ports (this main discussion), I think it makes sense to "announce" it in the FreeBSD Quarterly Status Report for Q2 which ends soon. While this has not yet been discussed, since I think about it, before I an AFK for a week, and in order to avoid being in a hurry to write something at the last moment, I wrote a report that I think match everyone's expectations. I opened a Draft PR here: The document is in a fork in our GitHub organization, so you can add commits to update the PR, iterate and discuss changes there. You are invited to do so! I went beyond what was discussed here, the idea is not to impose some way to do thing, but start a discussion about how we want to do this. I will be back on the 26th. When I catch up, it would help if I know you are okay with this. If I see changes, that will be trivial, but if my statements looks good to you and you have nothing to add, please still do something that help me see this has been reviewed in some way (:+1:, PR review, comment). Thanks! |
Hi, I have tested wazuh 4.4.4 with opensearch[-dashboards] 2.8.0 and It is working without problems. I was reading more about opensearch semver and I noted in theory 2.x version will not break anything before of 3.x is released because 2.x releases (2.6.x, 2.7.x, 2.8.x ...) do not add breaking changes. I mean we could update opensearch[-dashboards] safely. Otherwise, in rare case we could add a aditional opensearch* port version |
Hi, I have committed 2.8.0 to ports tree. @smortex thanks for PR. Take a look at https://cgit.freebsd.org/ports/commit/?id=e9ea52f0fdff54c9299a83fac61b5f3214056199 |
2023-06-06
I just started to update ports, started the build but have not tested yet.
2023-06-07
OpenSearch and OpenSearch-Dashboard start. Older dashboards / visualizations are not shown. Importing them seems to fail. Not sure why.