Description
When fixing issues with the specification, the most correct option is often a breaking change, and we have to implement workarounds instead, such as reusing existing classes with optional fields. We may want to clean some of this for Elasticsearch 9.0, as it will result in a cleaner, more future proof and more usable specification.
This issue is here to help us track such changes, so that we make them in time for 9.0 and include them in our changelogs.
- Modelling
wait_for_completion#1767 - Java issues batch 8 #2959 -> remodeling StepKey, splitting it into NextStep and CurrentStep
- ...
We also need to consider Elasticsearch breaking changes in the "Done - Accepted". As of 2024-10-01, those breaking changes affect the API:
- https://github.com/elastic/dev/issues/2783
- https://github.com/elastic/dev/issues/2751
- https://github.com/elastic/dev/issues/2746
- https://github.com/elastic/dev/issues/2811
- https://github.com/elastic/dev/issues/2753
- ...
Do we need to look at the >breaking label in the Elasticsearch repository? https://github.com/elastic/elasticsearch/pulls?q=is%3Apr+label%3A%3Ebreaking+label%3Av9.0.0+sort%3Acreated-asc There will be some overlap with the above.