Closed pgomulka closed 2 years ago
Pinging @elastic/es-core-infra (Team:Core/Infra)
re: Remove Repository Stats API #62309
: see #62309 as well as #62297 and #62308 -- this was /_snapshot/{repository}/_stats
and as @tlrx
observed "we're talking about an experimental API that was never released(behind a feature flag)." I think it's fair to assume we will not need to cover this via REST compatibility. @jakelandis do you concur?
REST Compatible API v7 completeness
As described in https://github.com/elastic/elasticsearch/issues/51816 all breaking changes could be subject to applying some compatibility at the REST layer to assist with upgrades. This issue exists to ensure that there is a complete and exhaustive list of all breaking changes and make the determination REST API compatibility should be applied.
A complete list of all breaking changes categorized by
The number of check boxes here should equal number of closed issues from this query: Eldest to newest breaking changes
Each line item should have a independent validation, and line items that require changes should be linked to the associated PR and issues. For specific compatibilities that require discussions, please open a new issue (as opposed to the comments of this issue).
Requires REST API compatibility with v7
Misc
//TODO: break up into better categories
cutoff_frequency
we could simply allow to parse these but do nothing. But forCommonTermsQuery
it looks more complex and I am not sure how to implement this without bringing too much code back.only_expunge_deletes
andmax_num_segments
set https://github.com/elastic/elasticsearch/pull/44761Types
These are mostly managed by https://github.com/elastic/elasticsearch/issues/54160. The issues here match 1:1 to the issues with
>breaking
label to help ensure the counts of breaking changes and number of checkboxes are equal.type
query https://github.com/elastic/elasticsearch/pull/47207include_type_name
parameter from REST layer https://github.com/elastic/elasticsearch/pull/48632Mappings
Unsure - needs more investigation
exclude_generated
that removes generated fields in GET config APIs https://github.com/elastic/elasticsearch/pull/63899Potentially leverage REST API compatibility, but out of immediate scope
scripting
EQL
=
for comparisons https://github.com/elastic/elasticsearch/pull/62756Does not require REST API compatibility with v7
Setttings
Settings are not subject to REST API compatibility. Often the changes behind the settings represent some behavior that is not carried forward.
_field_names
enabled setting https://github.com/elastic/elasticsearch/pull/46681Validation
Additional or stricter validation is a type of breaking change that can change the response of a request from a success to a specific failure. However, success -> error responses are not covered by REST API compatibility and is considered behavior.
Is actually breaking for 8.0 ?
Perhaps mislabeled or was beta/experimental and/or change was made in a minor
force
flag from _start https://github.com/elastic/elasticsearch/pull/46414 (feature was beta when this change was made)Misc