On 2021.12.01 16:57, Ævar Arnfjörð Bjarmason wrote: > [...] > > 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"). No objections from me, this sounds like a good improvement.
