Skip to content

Commit

Permalink
tweaks based on feedback
Browse files Browse the repository at this point in the history
Signed-off-by: Kyle Davis <[email protected]>
  • Loading branch information
stockholmux committed Feb 24, 2022
1 parent e0cef0b commit 4d14f1d
Showing 1 changed file with 7 additions and 7 deletions.
Original file line number Diff line number Diff line change
Expand Up @@ -3,7 +3,7 @@ layout: post
title: "Update: OpenSearch Proposed 2022 Release Schedule"
authors:
- henkle
date: 2022-02-23
date: 2022-02-24
categories:
- partners
twittercard:
Expand All @@ -22,10 +22,10 @@ Before getting to the dates themselves, here are the things I was thinking about
As a reminder, the OpenSearch project assigns version numbers to releases following [the semantic versioning convention](https://opensearch.org/blog/technical-post/2021/08/what-is-semver/). This means the project won’t introduce an incompatible change without also incrementing the major version number.

2. **Everyone is excited about Lucene 9.0.0.**
Lucene 9.0.0 [released](https://lucene.apache.org/core/corenews.html#apache-lucenetm-900-available) on December 7, 2021. It includes several new features and performance improvements that the team would like to make available to users of OpenSearch, including K-NN support, Vectors, Big Endian, Faster numeric indexing, faster sorting, concurrent merge scheduler, and prototype Java Jigsaw module support. It will take a few releases for OpenSearch to take full advantage of it, but the potential of Lucene 9.0.0 is so exciting getting support in as soon as possible is the priority over trying to bundle it with other changes.
Lucene 9.0.0 [released](https://lucene.apache.org/core/corenews.html#apache-lucenetm-900-available) on December 7, 2021. It includes several new features and performance improvements that the team would like to make available to users of OpenSearch, including K-NN support, Vectors, Big Endian, faster numeric indexing, faster sorting, concurrent merge scheduler, and prototype Java Jigsaw module support. Starting to use Lucene 9.0.0 as soon as possible is a priority. It will take a few releases to leverage the full value of it, but adding it now is so exciting and has loads of potential for OpenSearch.

3. **The project will follow a "release train" model for minor-version releases, and a "tentpole" model for major-version releases.**
The team wants to produce minor-version releases on a "release-train" schedule: every six weeks a new release comes out, and it includes all the new features that are ready at the time of release. Having a set release schedule makes sure OpenSearch is releasing in a predictable way and prevents a backlog of unreleased changes. In contrast, major-version releases will take place when there is a critical mass of new features that would create incompatibilities, since that’s the only opportunity to release them. These are called "tentpole" features because getting one of these in might hold a release. If any of the tentpole changes runs into serious problems, a decision would need to be made to move the release or wait until the next major release for that change.
The team wants to produce minor-version releases on a "release-train" schedule: every six weeks a new release comes out, and it includes all the new features that are ready at the time of release. Having a set release schedule makes sure OpenSearch is releasing in a predictable way and prevents a backlog of unreleased changes. In contrast, major-version releases will take place when there is a critical mass of new features that would create incompatibilities, since that’s the only opportunity to release them. These are called "tentpole" features because getting one of these in might hold a release. If any of the tentpole changes runs into serious problems, the contributors working on it will need to add a comment on their meta tracking issue with an alert. At that point, the contributors working on the issue and I can decide whether to cut scope, remove the feature from the release, or move the release date depending on the type and severity of the problem.



Expand Down Expand Up @@ -59,18 +59,18 @@ As mentioned above, the primary driver for the team to have an earlier 2.0.0 rel

#### 3.0.0

Some 2022 themes for the core of OpenSearch: Security, Efficiency, Durability, Extensibility, and Engagement. This is the release where those ideals are translated into changes you can use: Things like [segment replication](https://github.com/opensearch-project/OpenSearch/issues/1694), [inbuilt security](https://github.com/opensearch-project/OpenSearch/issues/1029) and [sandboxing](https://github.com/opensearch-project/OpenSearch/issues/1422). I’m excited to work with you to make those improvements, and to see your thoughts on how to make things even better.
Since Lucene 9 will be released with 2.0, the 3.0 release will contain the bulk of breaking changes planned for 2022. That list is not written in stone, but we already looking ahead to things like [segment replication](https://github.com/opensearch-project/OpenSearch/issues/1694), [inbuilt security](https://github.com/opensearch-project/OpenSearch/issues/1029) and [sandboxing](https://github.com/opensearch-project/OpenSearch/issues/1422). I’m excited to work with you to make those improvements, and to see your thoughts on how to make things even better.

### One final note....

Like all schedules, it’s possible that it will need to change based on real world conditions *cough* log4j *cough*. As the year goes along, if better way to do things are found, or someone has a brilliant idea for a feature, those changes will be made. If nothing else, in January of 2023 everyone can look back at this schedule with a wry smile at the bold confidence of February 2022.
Like all schedules, it’s possible that it will need to change based on real world conditions *cough* log4j *cough*. As the year goes along, if better ways to do things are found, or someone has a brilliant idea for a feature, those changes will be made. If nothing else, in January of 2023 everyone can look back at this schedule with a wry smile at the bold confidence of February 2022.

### Feedback?

Please make it known in the forums or on GitHub! Specifically:
Please make it known in [the forums](https://discuss.opendistrocommunity.dev/t/2022-release-schedule/8739)! Specifically:

1. Does this list of considerations make sense? What else should be taken into consideration?
2. Are there any errors in the way the dates are laid out?
3. What would a useful “public preview” look like to you? What would you want to get out of it?

As the public roadmap is populated with features, I look forward to also hearing your feedback on what’s going in as well.
As the public roadmap is populated with features, I look forward to also hearing your feedback on what’s going in as well.

0 comments on commit 4d14f1d

Please sign in to comment.