Thx! Makes sense. Would the API versioning then handle backwards compatibility problem with Logstash/Beats?
Yes, exactly…
If moving to 3.0 sooner will allow us to scale client support, reduce versioning headaches, and make it easy to move straight from 1.x to 3.x, then I am for option 1 as that is a win for the code and community.
Hey Nick;
Here are the things that are confusing me:
It seems like the primary argument is that moving to quickly to 3.0 makes it easier for for folks to upgrade to 3.0. But if we’re continuing to release on the 2.x line, I can’t see the benefit of doing that earlier?
As for clients, I think the horses are already out of the barn – We’re the ones who did the deprecation which broke them most recently-- so we’re also in control of not breaking them again (for the most part). For clients not controlled by us, AFAIK, we’ve pinned to a particular version (example: 7.17.1 for logstash here), so they should not be a source of breaking changes.
I agree that REST version API is definitely the way to go, but AFAIK, it’s not actively being worked on (it’s also not a breaking change, so we could add it as part of the 2.x line). I could absolutely be wrong about that, but I’m just not seeing anything happening right now. So I couldn’t promise anything would be ready for an August code freeze (unless you’re working on it?)
Finally, while I personally can see the benefit of having a clean break from Elastic, I don’t think that’s a priority for folks using the software. I’d hate to release a major version and cause disruption for something that doesn’t directly solve a problem for someone using the software. To ask another way: I understand the maintainer pain, but what is the pain for the end users on 2.x that would be removed if we moved to 3.x?
Thanks,
/C
1 Like
“The sooner we can migrate users away from these hacky integrations the better the OpenSearch experience will be; and this will be a breaking change that will require a major release.”
“Easier to upgrade to 3.0” is just a positive side effect of doing it w/ Lucene 9 instead of waiting to release 3.0 with Lucene 10.
I actually think we should release REST API in a major instead of a minor. Releasing in a minor makes it harder to discern between 2.x-PreAPI and 2.x-PostAPI without more mid-stream version juggling which has caused many of the bugs we’re seeing in 2.x today.
The ongoing bug reports and patch releases to fix bugs introduced due to version juggling to maintain Elastic and Client cross compatibility.
I think this is the main blocker. I started this work but my plate has been full; and most of the development effort is on long term architecture changes / new features and less on quickly fixing near term pain points like this. That makes it hard to move quickly even if we wanted to so I’m not sure we could make the penciled in August deadline.
Another quick observation: I haven’t seen many users chime in here on their preference of releasing 3.0 this year or next. In my experience, if a user doesn’t have a critical need for a new feature they typically prefer waiting until at least a minor or two release before bumping to the next major version. I speculate that’s part of what we’re seeing here. And if so, releasing 3.0 in October 2022 vs early 2023 may be moot to the users anyway. I’d love to hear otherwise.
Just wanted to chime in as a user on what would make this decision easier:
A more detailed pros and cons regarding other features.
Breaking compatability with Elasticsearch is major, many of our clients still use the Elasticsearch NEST client as the C# client isn’t released yet.
Even if it is, it will take some time until trust is gained, so for now, they still use NEST.
This is just one client, but the supporting community just isn’t there yet. It has started to move there, but many things (especially 3rd party) are not supported yet.
However, with all that said, killer features which will happen much sooner if 3.0 is released on schedule could move many of our clients.
So what exactly is likely to be delayed? What isn’t?
Do take note, “likely” is definitely enough. But a more thorough understanding of the downsides except “breaking from the Elastic chain” (which I can sympathise with, Elastic sucks as far as we’re concerned) could help sway our clients better here.
FYI Please refer to the poll results for decision on 3.0.0 dates - Poll: 3.0 release
1 Like