Add OpenSearch status report #189
Conversation
website/content/en/status/report-2023-04-2023-06/opensearch.adoc
Outdated
Show resolved
Hide resolved
website/content/en/status/report-2023-04-2023-06/opensearch.adoc
Outdated
Show resolved
Hide resolved
website/content/en/status/report-2023-04-2023-06/opensearch.adoc
Outdated
Show resolved
Hide resolved
|
PR updated, thanks! The OpenSearch team may still want to fine-tune the details of the changes described here, for this reason this PR is currently a draft. |
website/content/en/status/report-2023-04-2023-06/opensearch.adoc
Outdated
Show resolved
Hide resolved
| 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). | ||
|
|
||
| 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. |
There was a problem hiding this comment.
Do you mean "only provides updates for the latest minor version" here?
There was a problem hiding this comment.
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!
| 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. |
There was a problem hiding this comment.
As of today,
1.3.10is 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.0will ever be released.
2.8.0is the last 2.x major version. The next version should be2.9.0, but if some critical security issue is found, a2.8.1can be released quickly to just fix the security issue. Then2.9.0will follow according to the initial schedule (unless a new critical security issue is found and fixed in2.8.2). Once2.9.0is released, no more2.8.xwill 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?
There was a problem hiding this comment.
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.
Co-authored-by: Pau Amma <[email protected]>
website/content/en/status/report-2023-04-2023-06/opensearch.adoc
Outdated
Show resolved
Hide resolved
| 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. |
There was a problem hiding this comment.
@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?
|
@smortex @alonsobsd : Can you please confirm if you want to submit this report, and in case you do if it is ready for commit? Thanks. |
|
It looks like nobody took position in favor of a direction or another. IMHO this is status-quo, and therefore there is no need for a status report ATM. I am closing it. Or course, if needed, we can reopen this topic in the future 😉. Thank you all! |
No description provided.