{"thread":{"id":"56875","subject":"[PATCH] trace2: increment event format version","startedAt":"2021-11-11T22:34:33Z","lastAt":"2021-12-01T19:57:17Z","messageCount":9,"participants":["Josh Steadmon","Junio C Hamano","Ævar Arnfjörð Bjarmason","Jeff Hostetler"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"440942","messageId":"ebc4d9a6960f0350772c14981ef211876f29d0fa.1636669891.git.steadmon@google.com","threadId":"56875","inReplyTo":null,"subject":"[PATCH] trace2: increment event format version","fromName":"Josh Steadmon","fromEmail":"steadmon@google.com","sentAt":"2021-11-11T22:34:25Z","receivedAt":"2021-11-11T22:34:33Z","isPatch":true,"sender":{"key":"steadmon@google.com","avatar":"https://avatars.githubusercontent.com/u/2654920?v=4"},"body":"In 64bc752 (trace2: add trace2_child_ready() to report on background\nchildren, 2021-09-20), we added a new \"child_ready\" event. In\nDocumentation/technical/api-trace2.txt, we promise that adding a new\nevent type will result in incrementing the trace2 event format version\nnumber, but this was not done. Correct this in code & docs.\n\nSigned-off-by: Josh Steadmon <steadmon@google.com>\n---\n Documentation/technical/api-trace2.txt | 4 ++--\n trace2/tr2_tgt_event.c                 | 2 +-\n 2 files changed, 3 insertions(+), 3 deletions(-)\n\ndiff --git a/Documentation/technical/api-trace2.txt b/Documentation/technical/api-trace2.txt\nindex ef7fe02a8f..bb13ca3db8 100644\n--- a/Documentation/technical/api-trace2.txt\n+++ b/Documentation/technical/api-trace2.txt\n@@ -128,7 +128,7 @@ yields\n \n ------------\n $ cat ~/log.event\n-{\"event\":\"version\",\"sid\":\"sid\":\"20190408T191610.507018Z-H9b68c35f-P000059a8\",\"thread\":\"main\",\"time\":\"2019-01-16T17:28:42.620713Z\",\"file\":\"common-main.c\",\"line\":38,\"evt\":\"2\",\"exe\":\"2.20.1.155.g426c96fcdb\"}\n+{\"event\":\"version\",\"sid\":\"sid\":\"20190408T191610.507018Z-H9b68c35f-P000059a8\",\"thread\":\"main\",\"time\":\"2019-01-16T17:28:42.620713Z\",\"file\":\"common-main.c\",\"line\":38,\"evt\":\"3\",\"exe\":\"2.20.1.155.g426c96fcdb\"}\n {\"event\":\"start\",\"sid\":\"20190408T191610.507018Z-H9b68c35f-P000059a8\",\"thread\":\"main\",\"time\":\"2019-01-16T17:28:42.621027Z\",\"file\":\"common-main.c\",\"line\":39,\"t_abs\":0.001173,\"argv\":[\"git\",\"version\"]}\n {\"event\":\"cmd_name\",\"sid\":\"20190408T191610.507018Z-H9b68c35f-P000059a8\",\"thread\":\"main\",\"time\":\"2019-01-16T17:28:42.621122Z\",\"file\":\"git.c\",\"line\":432,\"name\":\"version\",\"hierarchy\":\"version\"}\n {\"event\":\"exit\",\"sid\":\"20190408T191610.507018Z-H9b68c35f-P000059a8\",\"thread\":\"main\",\"time\":\"2019-01-16T17:28:42.621236Z\",\"file\":\"git.c\",\"line\":662,\"t_abs\":0.001227,\"code\":0}\n@@ -391,7 +391,7 @@ only present on the \"start\" and \"atexit\" events.\n {\n \t\"event\":\"version\",\n \t...\n-\t\"evt\":\"2\",\t\t       # EVENT format version\n+\t\"evt\":\"3\",\t\t       # EVENT format version\n \t\"exe\":\"2.20.1.155.g426c96fcdb\" # git version\n }\n ------------\ndiff --git a/trace2/tr2_tgt_event.c b/trace2/tr2_tgt_event.c\nindex 70cfc2f77c..3a0014417c 100644\n--- a/trace2/tr2_tgt_event.c\n+++ b/trace2/tr2_tgt_event.c\n@@ -20,7 +20,7 @@ static struct tr2_dst tr2dst_event = { TR2_SYSENV_EVENT, 0, 0, 0, 0 };\n  * a new field to an existing event, do not require an increment to the EVENT\n  * format version.\n  */\n-#define TR2_EVENT_VERSION \"2\"\n+#define TR2_EVENT_VERSION \"3\"\n \n /*\n  * Region nesting limit for messages written to the event target.\n\nbase-commit: e9e5ba39a78c8f5057262d49e261b42a8660d5b9\n-- \n2.34.0.rc1.387.gb447b232ab-goog\n\n"},{"id":"440946","messageId":"xmqqh7cijnwx.fsf@gitster.g","threadId":"56875","inReplyTo":"ebc4d9a6960f0350772c14981ef211876f29d0fa.1636669891.git.steadmon@google.com","subject":"Re: [PATCH] trace2: increment event format version","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-11-11T23:03:10Z","receivedAt":"2021-11-11T23:03:15Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Josh Steadmon <steadmon@google.com> writes:\n\n> In 64bc752 (trace2: add trace2_child_ready() to report on background\n> children, 2021-09-20), we added a new \"child_ready\" event. In\n> Documentation/technical/api-trace2.txt, we promise that adding a new\n> event type will result in incrementing the trace2 event format version\n> number, but this was not done. Correct this in code & docs.\n>\n> Signed-off-by: Josh Steadmon <steadmon@google.com>\n> ---\n>  Documentation/technical/api-trace2.txt | 4 ++--\n>  trace2/tr2_tgt_event.c                 | 2 +-\n>  2 files changed, 3 insertions(+), 3 deletions(-)\n\nHmph, it seems to me that this is better done before the release,\nor am I mistaken?\n\n\n>\n> diff --git a/Documentation/technical/api-trace2.txt b/Documentation/technical/api-trace2.txt\n> index ef7fe02a8f..bb13ca3db8 100644\n> --- a/Documentation/technical/api-trace2.txt\n> +++ b/Documentation/technical/api-trace2.txt\n> @@ -128,7 +128,7 @@ yields\n>  \n>  ------------\n>  $ cat ~/log.event\n> -{\"event\":\"version\",\"sid\":\"sid\":\"20190408T191610.507018Z-H9b68c35f-P000059a8\",\"thread\":\"main\",\"time\":\"2019-01-16T17:28:42.620713Z\",\"file\":\"common-main.c\",\"line\":38,\"evt\":\"2\",\"exe\":\"2.20.1.155.g426c96fcdb\"}\n> +{\"event\":\"version\",\"sid\":\"sid\":\"20190408T191610.507018Z-H9b68c35f-P000059a8\",\"thread\":\"main\",\"time\":\"2019-01-16T17:28:42.620713Z\",\"file\":\"common-main.c\",\"line\":38,\"evt\":\"3\",\"exe\":\"2.20.1.155.g426c96fcdb\"}\n>  {\"event\":\"start\",\"sid\":\"20190408T191610.507018Z-H9b68c35f-P000059a8\",\"thread\":\"main\",\"time\":\"2019-01-16T17:28:42.621027Z\",\"file\":\"common-main.c\",\"line\":39,\"t_abs\":0.001173,\"argv\":[\"git\",\"version\"]}\n>  {\"event\":\"cmd_name\",\"sid\":\"20190408T191610.507018Z-H9b68c35f-P000059a8\",\"thread\":\"main\",\"time\":\"2019-01-16T17:28:42.621122Z\",\"file\":\"git.c\",\"line\":432,\"name\":\"version\",\"hierarchy\":\"version\"}\n>  {\"event\":\"exit\",\"sid\":\"20190408T191610.507018Z-H9b68c35f-P000059a8\",\"thread\":\"main\",\"time\":\"2019-01-16T17:28:42.621236Z\",\"file\":\"git.c\",\"line\":662,\"t_abs\":0.001227,\"code\":0}\n> @@ -391,7 +391,7 @@ only present on the \"start\" and \"atexit\" events.\n>  {\n>  \t\"event\":\"version\",\n>  \t...\n> -\t\"evt\":\"2\",\t\t       # EVENT format version\n> +\t\"evt\":\"3\",\t\t       # EVENT format version\n>  \t\"exe\":\"2.20.1.155.g426c96fcdb\" # git version\n>  }\n>  ------------\n> diff --git a/trace2/tr2_tgt_event.c b/trace2/tr2_tgt_event.c\n> index 70cfc2f77c..3a0014417c 100644\n> --- a/trace2/tr2_tgt_event.c\n> +++ b/trace2/tr2_tgt_event.c\n> @@ -20,7 +20,7 @@ static struct tr2_dst tr2dst_event = { TR2_SYSENV_EVENT, 0, 0, 0, 0 };\n>   * a new field to an existing event, do not require an increment to the EVENT\n>   * format version.\n>   */\n> -#define TR2_EVENT_VERSION \"2\"\n> +#define TR2_EVENT_VERSION \"3\"\n>  \n>  /*\n>   * Region nesting limit for messages written to the event target.\n>\n> base-commit: e9e5ba39a78c8f5057262d49e261b42a8660d5b9\n"},{"id":"440947","messageId":"YY2h5lO90vo3Dy42@google.com","threadId":"56875","inReplyTo":"xmqqh7cijnwx.fsf@gitster.g","subject":"Re: [PATCH] trace2: increment event format version","fromName":"Josh Steadmon","fromEmail":"steadmon@google.com","sentAt":"2021-11-11T23:06:14Z","receivedAt":"2021-11-11T23:06:22Z","isPatch":true,"sender":{"key":"steadmon@google.com","avatar":"https://avatars.githubusercontent.com/u/2654920?v=4"},"body":"On 2021.11.11 15:03, Junio C Hamano wrote:\n> Josh Steadmon <steadmon@google.com> writes:\n> \n> > In 64bc752 (trace2: add trace2_child_ready() to report on background\n> > children, 2021-09-20), we added a new \"child_ready\" event. In\n> > Documentation/technical/api-trace2.txt, we promise that adding a new\n> > event type will result in incrementing the trace2 event format version\n> > number, but this was not done. Correct this in code & docs.\n> >\n> > Signed-off-by: Josh Steadmon <steadmon@google.com>\n> > ---\n> >  Documentation/technical/api-trace2.txt | 4 ++--\n> >  trace2/tr2_tgt_event.c                 | 2 +-\n> >  2 files changed, 3 insertions(+), 3 deletions(-)\n> \n> Hmph, it seems to me that this is better done before the release,\n> or am I mistaken?\n\nIdeally yes, although I am not sure if there is anyone using traces who\nstrongly depends on the accuracy of the evt field. For release-blocking\nfixes (for lack of a better term), should I have sent this patch\ndifferently?\n"},{"id":"440949","messageId":"xmqqczn6jlvu.fsf@gitster.g","threadId":"56875","inReplyTo":"YY2h5lO90vo3Dy42@google.com","subject":"Re: [PATCH] trace2: increment event format version","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-11-11T23:47:01Z","receivedAt":"2021-11-11T23:47:07Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Josh Steadmon <steadmon@google.com> writes:\n\n> On 2021.11.11 15:03, Junio C Hamano wrote:\n>> Josh Steadmon <steadmon@google.com> writes:\n>> \n>> > In 64bc752 (trace2: add trace2_child_ready() to report on background\n>> > children, 2021-09-20), we added a new \"child_ready\" event. In\n>> > Documentation/technical/api-trace2.txt, we promise that adding a new\n>> > event type will result in incrementing the trace2 event format version\n>> > number, but this was not done. Correct this in code & docs.\n>> >\n>> > Signed-off-by: Josh Steadmon <steadmon@google.com>\n>> > ---\n>> >  Documentation/technical/api-trace2.txt | 4 ++--\n>> >  trace2/tr2_tgt_event.c                 | 2 +-\n>> >  2 files changed, 3 insertions(+), 3 deletions(-)\n>> \n>> Hmph, it seems to me that this is better done before the release,\n>> or am I mistaken?\n>\n> Ideally yes, although I am not sure if there is anyone using traces who\n> strongly depends on the accuracy of the evt field.\n\nRelieving us from having to keep track of the actual users is the\npoint of documenting to making promises ;-)\n\n> For release-blocking\n> fixes (for lack of a better term), should I have sent this patch\n> differently?\n\nI do not think so.\n\nThanks.\n"},{"id":"441035","messageId":"211112.867ddduhly.gmgdl@evledraar.gmail.com","threadId":"56875","inReplyTo":"xmqqczn6jlvu.fsf@gitster.g","subject":"Re: [PATCH] trace2: increment event format version","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2021-11-12T22:33:09Z","receivedAt":"2021-11-12T22:36:14Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Thu, Nov 11 2021, Junio C Hamano wrote:\n\n> Josh Steadmon <steadmon@google.com> writes:\n>\n>> On 2021.11.11 15:03, Junio C Hamano wrote:\n>>> Josh Steadmon <steadmon@google.com> writes:\n>>> \n>>> > In 64bc752 (trace2: add trace2_child_ready() to report on background\n>>> > children, 2021-09-20), we added a new \"child_ready\" event. In\n>>> > Documentation/technical/api-trace2.txt, we promise that adding a new\n>>> > event type will result in incrementing the trace2 event format version\n>>> > number, but this was not done. Correct this in code & docs.\n>>> >\n>>> > Signed-off-by: Josh Steadmon <steadmon@google.com>\n>>> > ---\n>>> >  Documentation/technical/api-trace2.txt | 4 ++--\n>>> >  trace2/tr2_tgt_event.c                 | 2 +-\n>>> >  2 files changed, 3 insertions(+), 3 deletions(-)\n>>> \n>>> Hmph, it seems to me that this is better done before the release,\n>>> or am I mistaken?\n>>\n>> Ideally yes, although I am not sure if there is anyone using traces who\n>> strongly depends on the accuracy of the evt field.\n>\n> Relieving us from having to keep track of the actual users is the\n> point of documenting to making promises ;-)\n>\n>> For release-blocking\n>> fixes (for lack of a better term), should I have sent this patch\n>> differently?\n>\n> I do not think so.\n\nJosh notes the \"child_ready\" event being new in this release, but the\nsame is true of the cmd_ancestry event added in 2f732bf15e6 (tr2: log\nparent process name, 2021-07-21)\n\nSo yeah, with both of those it makes sense to have this for v2.34.0.\n\nOn the field itself I also wonder if it's useful at all. I'd think\nanyone implementing a parser for the format would dispatch to a lookup\nhandling known keys, so having a version indicating \"new keys here\"\nseems rather useless.\n"},{"id":"441039","messageId":"xmqqlf1tnebt.fsf@gitster.g","threadId":"56875","inReplyTo":"211112.867ddduhly.gmgdl@evledraar.gmail.com","subject":"Re: [PATCH] trace2: increment event format version","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-11-12T23:28:54Z","receivedAt":"2021-11-12T23:28:58Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:\n\n> Josh notes the \"child_ready\" event being new in this release, but the\n> same is true of the cmd_ancestry event added in 2f732bf15e6 (tr2: log\n> parent process name, 2021-07-21)\n>\n> So yeah, with both of those it makes sense to have this for v2.34.0.\n\nYeah, thanks for an extra pair of eyes.\n"},{"id":"442780","messageId":"9ce9c989-5a8c-1d5c-cc7e-9447760ed110@jeffhostetler.com","threadId":"56875","inReplyTo":"211112.867ddduhly.gmgdl@evledraar.gmail.com","subject":"Re: [PATCH] trace2: increment event format version","fromName":"Jeff Hostetler","fromEmail":"git@jeffhostetler.com","sentAt":"2021-12-01T15:49:29Z","receivedAt":"2021-12-01T15:50:24Z","isPatch":true,"sender":{"key":"git@jeffhostetler.com","avatar":null},"body":"\n\nOn 11/12/21 5:33 PM, Ævar Arnfjörð Bjarmason wrote:\n> \n> On Thu, Nov 11 2021, Junio C Hamano wrote:\n> \n>> Josh Steadmon <steadmon@google.com> writes:\n>>\n>>> On 2021.11.11 15:03, Junio C Hamano wrote:\n>>>> Josh Steadmon <steadmon@google.com> writes:\n>>>>\n>>>>> In 64bc752 (trace2: add trace2_child_ready() to report on background\n>>>>> children, 2021-09-20), we added a new \"child_ready\" event. In\n>>>>> Documentation/technical/api-trace2.txt, we promise that adding a new\n>>>>> event type will result in incrementing the trace2 event format version\n>>>>> number, but this was not done. Correct this in code & docs.\n>>>>>\n...\n> \n> On the field itself I also wonder if it's useful at all. I'd think\n> anyone implementing a parser for the format would dispatch to a lookup\n> handling known keys, so having a version indicating \"new keys here\"\n> seems rather useless.\n> \n\nThat may be true, but it is easier to have a version number and\nallow parsers to ignore it, than it is to not have a version number\nand at some point in the future require parsers try to figure it\nout. IMHO.\n\nSo far we've only added new event types (cmd_ancestry and child_ready)\nand everything is in regular JSON forms, so parsing and dispatching\nis relatively easy and the version number is not really needed.\nBut, if in the future we decide to change the contents within one of\nthose events, then the version number may be significant.\n\nThanks,\nJeff\n\n"},{"id":"442781","messageId":"211201.86zgpk9u3t.gmgdl@evledraar.gmail.com","threadId":"56875","inReplyTo":"9ce9c989-5a8c-1d5c-cc7e-9447760ed110@jeffhostetler.com","subject":"Re: [PATCH] trace2: increment event format version","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2021-12-01T15:57:16Z","receivedAt":"2021-12-01T16:18:36Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Wed, Dec 01 2021, Jeff Hostetler wrote:\n\n> On 11/12/21 5:33 PM, Ævar Arnfjörð Bjarmason wrote:\n>> On Thu, Nov 11 2021, Junio C Hamano wrote:\n>> \n>>> Josh Steadmon <steadmon@google.com> writes:\n>>>\n>>>> On 2021.11.11 15:03, Junio C Hamano wrote:\n>>>>> Josh Steadmon <steadmon@google.com> writes:\n>>>>>\n>>>>>> In 64bc752 (trace2: add trace2_child_ready() to report on background\n>>>>>> children, 2021-09-20), we added a new \"child_ready\" event. In\n>>>>>> Documentation/technical/api-trace2.txt, we promise that adding a new\n>>>>>> event type will result in incrementing the trace2 event format version\n>>>>>> number, but this was not done. Correct this in code & docs.\n>>>>>>\n> ...\n>> On the field itself I also wonder if it's useful at all. I'd think\n>> anyone implementing a parser for the format would dispatch to a lookup\n>> handling known keys, so having a version indicating \"new keys here\"\n>> seems rather useless.\n>> \n>\n> That may be true, but it is easier to have a version number and\n> allow parsers to ignore it, than it is to not have a version number\n> and at some point in the future require parsers try to figure it\n> out. IMHO.\n>\n> So far we've only added new event types (cmd_ancestry and child_ready)\n> and everything is in regular JSON forms, so parsing and dispatching\n> is relatively easy and the version number is not really needed.\n> But, if in the future we decide to change the contents within one of\n> those events, then the version number may be significant.\n\nYes, exactly. Versioning it makes sense, I'm commenting specifically on\nthe criteria for bumping the version. I.e. this bit in\ntrace2/tr2_tgt_event.c (with my comments)::\n    \n     * The version should be incremented if new event types are added\n\nThat seems entirely useless, i.e. just ignore unknown types. If you get\nan unknown type you know something is new, no need for a version number\nbump for this case.\n\nIt adds no new information you're not getting with \"oh? a new field?\".\n\n     * if existing fields are removed, [...]\n\nUseful, you don't always know if the absence of a field means it won't\nbe there at all, or if something else is up, particularly if the field\nis optional. E.g. if we rename \"error\" to \"exception\" (or whatever) we\ndon't want an older consumer to report that there's no errors happening.\n\n     * [...]or if there are significant changes in\n     * interpretation of existing events or fields.\n\nCarving out \"significant changes\" seems rather odd.\n\nLet's just say \"any changes\"? E.g. I don't think my 2d3491b117c (tr2:\nlog N parent process names on Linux, 2021-08-27) qualifies as\nsignificant change, but why not bump the version even for that?\n\nIn that case it was part of a release where we bumped the version\nanyway, but let's come up with some sane criteria.\n\nWhat's \"significant\" is also entirely subjective. I think 2d3491b117c is\ntrivial in the context of the entirety of our trace2 data. But if all\nyou care about is logging process trees it's highly significant.\n\n     * Smaller changes, such as adding\n     * a new field to an existing event, do not require an increment to the EVENT\n     * format version.\n\nI'd think a new sub-field would be in the same class as a new top-level\nevent field, i.e. adding a version wouldn't add any information. It\nfalls under the same general rule that you can traverse future data with\nyour \"version\" in hand, and a whitelist of fields you know how to\nhandle. If the version is the same but you've got new unknown fields you\nshouldn't need to care.\n\nIOW I think this would make more sense as a version bumping criteria:\n\n    The version should be incremented whenever an existing consumer of\n    trace2 data might want to act differently based on the new data.\n\n    An exception to this is that any new event types do not merit\n    bumping the version number. E.g. we have a top-level event type\n    \"error\" now, but might hypothetically add a new \"warning\" type.\n    Such an addition won't require bumping the version.\n\n    Likewise adding new mandatory fields to existing events doesn't\n    require bumping the version. E.g. the \"error\" type has (as of\n    writing) a \"fmt\" and \"msg\" field. Let's say a future version adds an\n    \"id\" (as in unique id for the error) field, such an addition won't\n    require bumping the version.\n\n    In other words, consumers of the trace2 JSON format are expected to\n    walk the structure and only pick those things that they know about.\n    Any unknown fields the consumer doesn't know about can be safely\n    discarded. This won't apply if the version is bumped, then all bets\n    are off, and the meaning of existing fields may or may not have\n    changed.\n\n    The idea is to encourage additive changes over changes to existing\n    fields, and to reduce the work in maintaining the consumers of the\n    format.\n\n    As long as consumers ignore new unknown data they won't need to\n    be updated every time the format changes in any way, only for\n    potentially backwards-incompatible changes.\n\nWouldn't this be a saner policy for version bumping? AFAICT the only\nthing you wouldn't be getting that you're getting now is the trivial\noptimization of being able to say cheaply route trace2 payloads based on\nversion number alone (but even that is iffy now due to the subjectivity\nof \"significant change\").\n"},{"id":"442795","messageId":"YafTgiNl53FeWH+Q@google.com","threadId":"56875","inReplyTo":"211201.86zgpk9u3t.gmgdl@evledraar.gmail.com","subject":"Re: [PATCH] trace2: increment event format version","fromName":"Josh Steadmon","fromEmail":"steadmon@google.com","sentAt":"2021-12-01T19:56:50Z","receivedAt":"2021-12-01T19:57:17Z","isPatch":true,"sender":{"key":"steadmon@google.com","avatar":"https://avatars.githubusercontent.com/u/2654920?v=4"},"body":"On 2021.12.01 16:57, Ævar Arnfjörð Bjarmason wrote:\n> [...]\n>\n> IOW I think this would make more sense as a version bumping criteria:\n> \n>     The version should be incremented whenever an existing consumer of\n>     trace2 data might want to act differently based on the new data.\n> \n>     An exception to this is that any new event types do not merit\n>     bumping the version number. E.g. we have a top-level event type\n>     \"error\" now, but might hypothetically add a new \"warning\" type.\n>     Such an addition won't require bumping the version.\n> \n>     Likewise adding new mandatory fields to existing events doesn't\n>     require bumping the version. E.g. the \"error\" type has (as of\n>     writing) a \"fmt\" and \"msg\" field. Let's say a future version adds an\n>     \"id\" (as in unique id for the error) field, such an addition won't\n>     require bumping the version.\n> \n>     In other words, consumers of the trace2 JSON format are expected to\n>     walk the structure and only pick those things that they know about.\n>     Any unknown fields the consumer doesn't know about can be safely\n>     discarded. This won't apply if the version is bumped, then all bets\n>     are off, and the meaning of existing fields may or may not have\n>     changed.\n> \n>     The idea is to encourage additive changes over changes to existing\n>     fields, and to reduce the work in maintaining the consumers of the\n>     format.\n> \n>     As long as consumers ignore new unknown data they won't need to\n>     be updated every time the format changes in any way, only for\n>     potentially backwards-incompatible changes.\n> \n> Wouldn't this be a saner policy for version bumping? AFAICT the only\n> thing you wouldn't be getting that you're getting now is the trivial\n> optimization of being able to say cheaply route trace2 payloads based on\n> version number alone (but even that is iffy now due to the subjectivity\n> of \"significant change\").\n\nNo objections from me, this sounds like a good improvement.\n"}]}