-
Notifications
You must be signed in to change notification settings - Fork 417
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Split ecs.version into parts #842
Comments
This reminds me of elastic/elasticsearch#48878 Would be nice to have support for it directly in ES. |
Yes, we're not going to add discrete major/minor/patch fields exactly because We haven't had time to investigate how to integrate them broadly in the schema yet. So I'm not sure if they can be a drop-in replacement for the current But anyone is welcome to step forward here and help on this :-) |
Ah, apparently the relevance of ECS was raised on that issue earlier by webmat. elastic/elasticsearch#48878 (comment) Is there anything worthwhile doing for ECS in the interim? I don't know the roadmap for the ES issue. I can continue using the workarounds for the time being, but if this is something of priority to others, I can tackle the major/minor/patch for now, and we can change the data type of |
One thing that would be nice to add is a vendor version - for vendors (or users) tracking their particular implementation versions. |
Yes - given that work in ES for the |
Scenario
ecs.version
is good information for compatibility, but because it's a string, it's actually non-trivial to write a query that validates semver. If we addmajor
,minor
andpatch
then we can match this much better.Problem
For instance, let's say I want to search my data for semantic matches for 1.3.0, because that's the first version that has a field I'm looking for. I could write that in KQL a few different ways:
ecs.version:(1.3.0 or 1.4.0 or 1.5.0 or 1.6.0 or 1.7.0 or ...)
ecs.version:1.* and ecs.version >= 1.3.0
But both have problems. The first requires you to know all of the versions. It also doesn't check for patch versions, but those could be done by replacing
.0
with.*
.The second approach does a string comparison and not a semantic comparison. That would mean that we'd miss
1.10.0
when comparing>= 1.3.0
, since>=
is lexicographical.Proposal
We should still keep
ecs.version
. It's super cheap anyway and contains the full string. But we can also addecs.major
,ecs.minor
andecs.patch
. If they are stored as numbers then we can make semantic validation trivial:ecs.major: 1 and ecs.minor >= 3
. Even if we're comparing to a hypothetically patched 1.3.2, we could doecs.major:1 and (ecs.minor:3 and ecs.patch:2 or ecs.minor > 3)
.The text was updated successfully, but these errors were encountered: