Any suggestion for breaking changes should be submitted via their own github issue, not as a comment on this issue.

Decided

Schema

• Remove guidance to lowercase http.request.method #1363 Remove guidance to lowercase http.request.method
• Remove Go code generator #1567 Remove or relocate the Go library and the code generating it
  • Need to confirm if the library will remain a Beats dependency in future releases.
• RFC 0017 - remove log.original field #1580 RFC 0017 Remove log.original
• Remove host.user.* fields #1362 Remove host.user.*
• Remove process.ppid field #1596 Remove process.ppid, now that we have all of process.parent.* (which includes the equivalent field process.parent.pid)

Tooling

• Remove --oss flag from ECS generator script #1340 Remove --oss flag
• Remove use cases directory and code #632 Remove use-cases directory and associated code
• Remove Golang dependencies #630

Under consideration

Tooling

• [meta] Consolidate generated ES index templates #1587 Remove legacy templates as generated artifacts.

No longer under consideration for 8.0

Items previous listed as Under consideration but subsequently removed. May still have value in the future, so capturing below.

• http.response.status_code as long instead of keyword or integer #564 Do we need to change the type of http.response.status_code to keyword, in order to allow users to bucket HTTP traffic by status code?
• Adopting new version field type #887 [RFC] Version Type Field Migration - Stage 0 #1309 Introduce the version data type for version fields
• [RFC] Label fields for additional types - Stage 0 #1341 Add other types of labels, potentially nested within labels.*, e.g. labels.long.*
• Does migrating @timestamp from date to date_nanos require a breaking change, or are the types compatible? Support for nanosecond timestamps (date_nanos) #1065
  • The two types are compatible, but with 64-bit integers not supported in Javascript, Kibana has several outstanding issues (64 bit number/integer support in Kibana kibana#40183, Canvas needs to support date_nanos kibana#41441, [Logs UI] The UI throws error when @timestamp format is date_nanos kibana#88290) that would create a degraded experience if data_nanos was the default for @timestamp, I think.
  • May still be able to provide guidance for those ECS users who require the additional precision of date_nanos and understand the possible side-effects.
• Update related.* field names from singular to plural #909 Update singular names to plural in the related.* field set.
  • The cost of introducing this as a breaking change outweighs the inconsistency in the naming. Not pursuing at this time.
• Fix the timestamps on file.* to be less Linux-centric
  • I see why the file timestamp fields could introduce confusion, but I also think with the new usage documentation sections we might be able to provide better guidance without changing the field names. Other tools/languages/libraries also use mtime, ctime, and atime to report on timestamps, even across different filesystems and OS types.
• Having category fields that don't assume a document is a time-based event
  • Happy to revisit this item, but I'm not finding any past context. Also not aware of any recent use cases.
  • We want to continue expanding ECS to better support full-text search use cases (searchable corpora), but if we need to add categories or other event kinds/categories/types, I don't see those as breaking changes.
• Adjust case normalization in accordance with upcoming query time case sensitivity
  • For some use cases, the original case of a value is something we want to preserve. Some short keyword fields, like protocol names, may remain good candidates for normalizing to all lowercase.
  • The case_insensitive parameter is available on some query types since 7.10. This provides an option to case-insensitivty matching without worrying about the original value's casing in ECS.
  • Could extend the normalize parameter introduced in Mark which fields should be arrays. #727 to identify lowercase fields in the schema docs.
  • Remove "implementing ECS" reference from field descriptions #1364 Remove "implementing ECS" pointer from normalized fields' descriptions.
• Clarify guidance on OS detail fields so they're populated more consistently across sources. (related Operating System field for Linux, Windows, macOS #576)
• Add meta information to fields where this applied #721 Where could the emerging standard metadata entries fit into ECS? Document standard metadata entries. elasticsearch#61941
• Deprecate host.hostname to avoid confusion between host.hostname and host.name
  https://github.com/elastic/observability-dev/issues/1056
  • Host identifiers RFC
• User.hash vs. new hash.* fields #483 Reuse hash.* underneath user.* in place of user.hash?