Should we move the "version" field under the "keyword" family type

[cbuescher]

When we introduced the version field type for semantic version strings, we aimed at making it compatible with the "keyword" field type. However, currently the field type has its own "type" name in the _field_caps output. The QL team recently got requests for support of this field type and apparently if a field type is added in an existent family that QL already supports, it makes that new field type being supported by default. We might want to consider moving version under the keyword family as well.
I'm opening this issue for discussion especially around backward compatibility concerns and to check if the field type really meets the requirements that are necessary to be moved under the keyword family. For example, we recently saw that _terms_enum currently isn't supported for this field type (#83403).

[elasticmachine]

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

[jtibshirani]

Adding some background: we had a discussion while adding the new version type, and at the time didn't think it made sense to add to the keyword family. Types within a family are guaranteed to behave exactly the same, the only difference being performance or space usage (like keyword vs. constant_keyword, etc.) However version actually has different behavior: range queries and sorting give different results. This didn't really fit the definition of "being in the same family" and it seemed like it could cause confusion to present it as keyword. If you switched from one type to the other, or queried across indices where they were both defined, there would be a result mismatch.

[astefan]

I understand the reason behind the decision and it seems logic to keep it outside of the keyword family.

One additional comment I want to make though, maybe this will come up in future discussions for other data types: the cost of adding support for one data type in QL in general (EQL, SQL or any other future language) is significant. There is a cost that is common to all languages but there are aspects that are unique to each language that need to be considered.
By contrast, making a data type part of a types family that already exists and has support in QL, has a cost that boils down to considering that new data type in tests only, which is significantly smaller than the former approach.

[cbuescher]

I understand the reason behind the decision and it seems logic to keep it outside of the keyword family.

Thanks, thats the route we will take after another team discussion.

this will come up in future discussions for other data types: the cost of adding support for one data type in QL [...] is significant.

Thanks for raising that concern again, it will be on our mind, the cost of adding new field types is also non-neligible on our end so we try to keep away from having to do that as much as possible. There are cases though where it makes sense, so we will think a lot about family-type compatibility in the future.