Add version_range as a range field type

[ajosh0504]

Description

Range field types represent a continuous range of values between an upper or lower bound. There are several range field types supported by Elasticsearch as of today. Version numbers seem like a natural fit for range field types, given that versions are often expressed as <, >, <=, >= , and hence would be good to include in the list.

Versioning is an important component of production-level software engineering. I can speak for my team, which trains machine learning models every month and saves versioned model training metadata into Elasticsearch. Being able to aggregate the data by model versions would be extremely useful.

Another use-case for version ranges is in enrich processors, where users might want to enrich existing data with version-related information, for example, enriching documents with software vulnerability information based on the software version.

[elasticmachine]

Pinging @elastic/es-data-management (Team:Data Management)

[elasticmachine]

Pinging @elastic/es-search (Team:Search)

[cbuescher]

Just for the record, this was already planned as part of #48878 but in the end the range field was split from the main version field work to simplify the PR. There was a WIP prototype PR for the range work that seemed doable at the time, but it would definitely need to be updated and polished.

[ajosh0504]

Any plans for when this work will be picked back up?

[ajosh0504]

That said, if the work for version_range field type in particular is going to be tracked in #48878 in the future, I can close this issue.

[cbuescher]

No current plans, lets keep this issue open because you also state a use-case where your team would need it.

[geekpete]

Mentioning that being able to match against a version range (similar to the ip range type that allows native matching against ip ranges) opens up a range of use cases wherever version data is being used that could leverage this native range type for multiple products across all Observability, Security and Enterprise Search solutions. Without the range type, doing certain kinds of range matches can be extremely tedious and those scenarios can be greatly simplified by just storing a range to match against natively. The original enhancement envisioned the version range type as a key feature to go along with the version type, it'd be a shame to half-implement the idea that has so much value. I do understand this all needs to fit within prioritization challenges.

[elasticsearchmachine]

Pinging @elastic/es-search-foundations (Team:Search Foundations)