All of lore.kernel.org
 help / color / mirror / Atom feed
From: Josh Steadmon <steadmon@google.com>
To: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
Cc: Jeff Hostetler <git@jeffhostetler.com>,
	Junio C Hamano <gitster@pobox.com>,
	Jeff Hostetler <jeffhost@microsoft.com>,
	git@vger.kernel.org, Emily Shaffer <emilyshaffer@google.com>
Subject: Re: [PATCH] trace2: increment event format version
Date: Wed, 1 Dec 2021 11:56:50 -0800	[thread overview]
Message-ID: <YafTgiNl53FeWH+Q@google.com> (raw)
In-Reply-To: <211201.86zgpk9u3t.gmgdl@evledraar.gmail.com>

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.

      reply	other threads:[~2021-12-01 19:57 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-11 22:34 [PATCH] trace2: increment event format version Josh Steadmon
2021-11-11 23:03 ` Junio C Hamano
2021-11-11 23:06   ` Josh Steadmon
2021-11-11 23:47     ` Junio C Hamano
2021-11-12 22:33       ` Ævar Arnfjörð Bjarmason
2021-11-12 23:28         ` Junio C Hamano
2021-12-01 15:49         ` Jeff Hostetler
2021-12-01 15:57           ` Ævar Arnfjörð Bjarmason
2021-12-01 19:56             ` Josh Steadmon [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YafTgiNl53FeWH+Q@google.com \
    --to=steadmon@google.com \
    --cc=avarab@gmail.com \
    --cc=emilyshaffer@google.com \
    --cc=git@jeffhostetler.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=jeffhost@microsoft.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.