Re: [PATCH] trace2: increment event format version

> [...]
>
> IOW I think this would make more sense as a version bumping criteria:
> 
>     The version should be incremented whenever an existing consumer of
>     trace2 data might want to act differently based on the new data.
> 
>     An exception to this is that any new event types do not merit
>     bumping the version number. E.g. we have a top-level event type
>     "error" now, but might hypothetically add a new "warning" type.
>     Such an addition won't require bumping the version.
> 
>     Likewise adding new mandatory fields to existing events doesn't
>     require bumping the version. E.g. the "error" type has (as of
>     writing) a "fmt" and "msg" field. Let's say a future version adds an
>     "id" (as in unique id for the error) field, such an addition won't
>     require bumping the version.
> 
>     In other words, consumers of the trace2 JSON format are expected to
>     walk the structure and only pick those things that they know about.
>     Any unknown fields the consumer doesn't know about can be safely
>     discarded. This won't apply if the version is bumped, then all bets
>     are off, and the meaning of existing fields may or may not have
>     changed.
> 
>     The idea is to encourage additive changes over changes to existing
>     fields, and to reduce the work in maintaining the consumers of the
>     format.
> 
>     As long as consumers ignore new unknown data they won't need to
>     be updated every time the format changes in any way, only for
>     potentially backwards-incompatible changes.
> 
> Wouldn't this be a saner policy for version bumping? AFAICT the only
> thing you wouldn't be getting that you're getting now is the trivial
> optimization of being able to say cheaply route trace2 payloads based on
> version number alone (but even that is iffy now due to the subjectivity
> of "significant change").