Breaking changes considered for 9.0

[pquentin]

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.

• Remove support for deprecated force_source highlighting parameter elasticsearch#116943
• ...

[javanna]

Hey, I see this issue links the removal of force_source highlighting parameter. Does that require any adjustments in practice?

[pquentin]

Hey Luca, yes it needs to be removed here:

elasticsearch-specification/specification/_global/search/_types/highlighting.ts

Lines 71 to 74 in cf7d574

	/**
	* @deprecated 8.8.0
	*/
	force_source?: boolean

.