Re: [PATCH] trace2: increment event format version

["Ævar Arnfjörð Bjarmason" <avarab@gmail.com>]

On Thu, Nov 11 2021, Junio C Hamano wrote:

> Josh Steadmon <steadmon@google.com> writes:
>
>> On 2021.11.11 15:03, Junio C Hamano wrote:
>>> Josh Steadmon <steadmon@google.com> writes:
>>> 
>>> > In 64bc752 (trace2: add trace2_child_ready() to report on background
>>> > children, 2021-09-20), we added a new "child_ready" event. In
>>> > Documentation/technical/api-trace2.txt, we promise that adding a new
>>> > event type will result in incrementing the trace2 event format version
>>> > number, but this was not done. Correct this in code & docs.
>>> >
>>> > Signed-off-by: Josh Steadmon <steadmon@google.com>
>>> > ---
>>> >  Documentation/technical/api-trace2.txt | 4 ++--
>>> >  trace2/tr2_tgt_event.c                 | 2 +-
>>> >  2 files changed, 3 insertions(+), 3 deletions(-)
>>> 
>>> Hmph, it seems to me that this is better done before the release,
>>> or am I mistaken?
>>
>> Ideally yes, although I am not sure if there is anyone using traces who
>> strongly depends on the accuracy of the evt field.
>
> Relieving us from having to keep track of the actual users is the
> point of documenting to making promises ;-)
>
>> For release-blocking
>> fixes (for lack of a better term), should I have sent this patch
>> differently?
>
> I do not think so.

Josh notes the "child_ready" event being new in this release, but the
same is true of the cmd_ancestry event added in 2f732bf15e6 (tr2: log
parent process name, 2021-07-21)

So yeah, with both of those it makes sense to have this for v2.34.0.

On the field itself I also wonder if it's useful at all. I'd think
anyone implementing a parser for the format would dispatch to a lookup
handling known keys, so having a version indicating "new keys here"
seems rather useless.