Please stabilize APIs between minor releases when at all possible
Closed this issue · 5 comments
Hi Elastic .NET team.
I've been using Elastic for .NET 8.* for 2 years now and many times I try to do an upgrade I end up having to fix one or more sections of code (sometimes many if I'm using the Elastic fluent syntax).
I've never used any other library that had so many breaking changes between minor releases.
I'm starting to go away from using any of the Elastic Fluent syntax because of the many breaking changes that happen between minor versions, but even the Transport calls tend to break as well. (There are many overloads, and all of a sudden one disappears and now we have to refactor in many places).
E.g. When I upgraded to 8.19.* from 8.18.* all of a sudden I'm getting multiple syntax errors for Elastic Fluent syntax, as well as a Transport.IndexAsync error because the overload for (document, IndexName, CancellationToken) has been removed.
Can someone explain why there is so much churn in between minor releases? Its not like removing an API like the transport one mentioned above improves anything... Or does it?
Thanks, really love Elastic and glad we have a .NET library, but would like to see it stabilize a bit more.
Hi @JamesPScottPharm3r ,
the "Versioning" section of the README explains why it's not always possible to avoid breaking changes in a minor version release of the client. Please also note that we don't (can't) strictly use semantic versioning. The linked "breaking changes policy" further goes into details.
In case of the .NET client, we had to improve the code generator quite significantly a few times since usability of the generated code was way too low. With the latest generation this area has improved significantly! This new generator was initially only used for the 9.x releases due to all the breaking changes.
Since 8.19 is the LTS branch of 8.x and a lot of users still need ES 8 support, I made a deliberate choice to backport all the good improvements to this branch. The 9.0 breaking changes should cover all things, in case you need further assistance with the upgrade.
I'm sorry for the inconvenience caused by this decision, but I'm sure in the end the benefits will outweigh the trouble.
That being said, I don't expect massively breaking changes like this again in the foreseeable future.
Hi Florian,
Thanks for taking the time to respond. We use Elastic quite a bit throughout our code and impacts like this effect our schedules. So we are looking forward to additional stabilization in the future.
Another option could be to find ways of keeping the old compatibilities while still introducing new features. I understand the additional burden this would place on your team, but it would certainly help us developers using the library.
Thanks again, and appreciate the teams work.
James
Another option could be to find ways of keeping the old compatibilities while still introducing new features. I understand the additional burden this would place on your team, but it would certainly help us developers using the library.
This is of course something I try to do whenever possible (deprecating code first instead of instantly removing it). However, this is not always possible. This document is another good read (Java client, but applies to .NET as well): https://www.elastic.co/docs/reference/elasticsearch/clients/java/breaking-changes-policy
So we are looking forward to additional stabilization in the future.
There are no plans to heavily modify the code generator again in the forseeable future, since we are currently very happy with the results. This means that the only breaking changes you might experience are the ones driven by fixes in the Elasticsearch specification (see the linked document).
This issue is stale because it has been open 5 days with no activity. Remove stale label or comment or this will be closed in 2 days.
This issue was closed because it has been stalled for 2 days with no activity.