So one of the best things about doing things is you learn things, so the next time you do them you’re better at them.
We just released OpenSearch 2.0 and we learned a couple of things:
1/ Having a long gap between 2.0 release candidate and 2.0 release makes it weird to build features. We didn’t want to put features into 2.0 after the RC cut off, but then we also didn’t want to release things into 1.x that weren’t in 2.0.
2/ Having an RC is good in theory, but we didn’t get a lot of feedback on the RC itself.
3/ Even if we didn’t get user feedback on the RC, we definitely needed to have a hard integration point to add extra testing for breaking changes.
The plan of record right now for OpenSearch 3.0 is to put out an RC in September with a full release in January. Based on what we learned above, I’m leaning towards tightening up the time between the RC and full release to ~4 weeks, with only one minor version between them and to see if there are better ways to get feedback on the RC/beta.
But wait, there’s more:
As I started to look at head to 3.0, I realize that we might not need another major release. As a reminder, OpenSearch follows semver, which means we only release breaking changes in major versions. For our minor releases we follow a train model, where we release every 6 weeks or so. When I was planning the year out, I thought that some of the features we were planning for this year would require a major version because they would have breaking changes in them. But as we’ve built them out, we’ve realized that these features are actually additive and will not break any existing functionality. Since upgrading to major versions can be disruptive for people, if we have an opportunity to continue to build on the 2.x platform we should at least consider it.
Open Questions:
If we are going to do a second major release this year:
What do you think the right gap is between the Beta/RC and the final release?
What can we do to get better feedback on the RC/Beta?
If we’re not going to do a second major release this year
Are there any breaking changes you were planning for 3.0? If so, what are they, and what would the impact be if we moved out our next major release into 2023 (with Lucene 10)?
Are there any knock on effects (like having to continue to support spoofing for older versions) that we haven’t considered that would recommend doing a major release?
Proposed Schedules
The current schedule plan lives here for reference.
If we left 3.0 in as a major release, but shortened the time between the RC and the beta, it might look like this:
Release Number | Code Freeze Date | Release Date |
---|---|---|
1.3.3 | June 03 2022 | June 09 2022 |
2.1 | June 23rd | June 30th |
1.3.4 | July 01 2022 | July 07 2022 |
2.2 | August 4th | Aug 11th |
1.3.5 | August 16th | August 23rd |
3.0.0 RC | OpenSearch Core/Dashboards : August 11th | |
Plugins and Clients: August 18th | September 14th | |
2.3.1 | September 22nd | September 29th |
3.0.0 | September 30 2022 | October 06 2022 |
3.1.0 | November 04 2022 | November 10 2022 |
1.3.6 | December 1st | December 8th |
3.2 | January 10th, 2023 | January 12th 2023 |
If moved 3.0 out into 2023, things might look like this:
Release Number | Code Freeze Date | Release Date |
---|---|---|
1.3.3 | June 03 2022 | June 09 2022 |
2.1 | June 23rd | June 30th |
1.3.4 | July 01 2022 | July 07 2022 |
2.2 | August 4th | Aug 11th |
1.3.5 | August 16th | August 23rd |
2.3 | September 7th | September 14th |
1.3.6 | September 30 2022 | October 06 2022 |
2.4 | November 04 2022 | November 10 2022 |
1.3.7 | December 1st | December 8th |
2.5 | January 10th, 2023 | January 12th 2023 |
What do you think?
We will also be discussing this proposal at the Tuesday, June 21st Community Meeting. Hope to see you there.
/C