From: Eric Blake <eblake@redhat.com>
To: Fam Zheng <famz@redhat.com>, qemu-devel@nongnu.org
Cc: Kevin Wolf <kwolf@redhat.com>,
qemu-trivial@nongnu.org, Markus Armbruster <armbru@redhat.com>,
Luiz Capitulino <lcapitulino@redhat.com>
Subject: Re: [Qemu-trivial] [PATCH v2] qapi: Document optional arguments' backwards compatibility
Date: Tue, 06 May 2014 19:30:34 -0600 [thread overview]
Message-ID: <53698CBA.7040901@redhat.com> (raw)
In-Reply-To: <1399341953-14387-1-git-send-email-famz@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 2290 bytes --]
On 05/05/2014 08:05 PM, Fam Zheng wrote:
> Signed-off-by: Fam Zheng <famz@redhat.com>
>
> ---
> v2: Employ the text suggested by Eric. (Thanks!)
Since much of it is my wording, it's probably better to credit me as an
author, by adding:
Signed-off-by: Eric Blake <eblake@redhat.com>
>
> Signed-off-by: Fam Zheng <famz@redhat.com>
> ---
> docs/qapi-code-gen.txt | 26 ++++++++++++++++++++++----
> 1 file changed, 22 insertions(+), 4 deletions(-)
>
> +The use of '*' as a prefix to the name means the member is optional.
> +
> +The default initialization value of an optional argument should not be changed
> +between versions of QEMU unless the new default maintains backward
> +compatibility to the user-visible behavior of the old default.
Maybe worth adding:
With proper documentation, this policy still allows some flexibility;
for example, documenting that a default of 0 picks an optimal buffer
size allows one release to declare the optimal size at 512 while another
release declares the optimal size at 4096 - the user-visible behavior is
not the bytes used by the buffer, but the fact that the buffer was
optimal size.
> +
> +On input structures (only mentioned in the 'data' side of a command), changing
> +from mandatory to optional is safe (older clients will supply the option, and
> +newer clients can benefit from the default); changing from optional to
> +mandatory is backwards incompatible (older clients may be omitting the option,
> +and must continue to work).
> +
> +On output structures (only mentioned in the 'returns' side of a command),
> +changing from mandatory to optional is in general unsafe (older clients may be
> +expecting the field, and could crash if it is missing), although it can be done
> +if the only way that the optional argument will be omitted is when it is
> +triggered by the presence of a new input flag to the command that older clients
> +don't know to send. Changing from optional to mandatory is safe.
> +
> +A structure that is used in both input and output of various commands
> +must consider the backwards compatibility constraints of both directions
> +of use.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: Eric Blake <eblake@redhat.com>
To: Fam Zheng <famz@redhat.com>, qemu-devel@nongnu.org
Cc: Kevin Wolf <kwolf@redhat.com>,
qemu-trivial@nongnu.org, Markus Armbruster <armbru@redhat.com>,
Luiz Capitulino <lcapitulino@redhat.com>
Subject: Re: [Qemu-devel] [PATCH v2] qapi: Document optional arguments' backwards compatibility
Date: Tue, 06 May 2014 19:30:34 -0600 [thread overview]
Message-ID: <53698CBA.7040901@redhat.com> (raw)
In-Reply-To: <1399341953-14387-1-git-send-email-famz@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 2290 bytes --]
On 05/05/2014 08:05 PM, Fam Zheng wrote:
> Signed-off-by: Fam Zheng <famz@redhat.com>
>
> ---
> v2: Employ the text suggested by Eric. (Thanks!)
Since much of it is my wording, it's probably better to credit me as an
author, by adding:
Signed-off-by: Eric Blake <eblake@redhat.com>
>
> Signed-off-by: Fam Zheng <famz@redhat.com>
> ---
> docs/qapi-code-gen.txt | 26 ++++++++++++++++++++++----
> 1 file changed, 22 insertions(+), 4 deletions(-)
>
> +The use of '*' as a prefix to the name means the member is optional.
> +
> +The default initialization value of an optional argument should not be changed
> +between versions of QEMU unless the new default maintains backward
> +compatibility to the user-visible behavior of the old default.
Maybe worth adding:
With proper documentation, this policy still allows some flexibility;
for example, documenting that a default of 0 picks an optimal buffer
size allows one release to declare the optimal size at 512 while another
release declares the optimal size at 4096 - the user-visible behavior is
not the bytes used by the buffer, but the fact that the buffer was
optimal size.
> +
> +On input structures (only mentioned in the 'data' side of a command), changing
> +from mandatory to optional is safe (older clients will supply the option, and
> +newer clients can benefit from the default); changing from optional to
> +mandatory is backwards incompatible (older clients may be omitting the option,
> +and must continue to work).
> +
> +On output structures (only mentioned in the 'returns' side of a command),
> +changing from mandatory to optional is in general unsafe (older clients may be
> +expecting the field, and could crash if it is missing), although it can be done
> +if the only way that the optional argument will be omitted is when it is
> +triggered by the presence of a new input flag to the command that older clients
> +don't know to send. Changing from optional to mandatory is safe.
> +
> +A structure that is used in both input and output of various commands
> +must consider the backwards compatibility constraints of both directions
> +of use.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]
next prev parent reply other threads:[~2014-05-07 1:31 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-06 2:05 [Qemu-trivial] [PATCH v2] qapi: Document optional arguments' backwards compatibility Fam Zheng
2014-05-06 2:05 ` [Qemu-devel] " Fam Zheng
2014-05-07 1:30 ` Eric Blake [this message]
2014-05-07 1:30 ` Eric Blake
2014-05-07 1:57 ` [Qemu-trivial] " Fam Zheng
2014-05-07 1:57 ` Fam Zheng
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=53698CBA.7040901@redhat.com \
--to=eblake@redhat.com \
--cc=armbru@redhat.com \
--cc=famz@redhat.com \
--cc=kwolf@redhat.com \
--cc=lcapitulino@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-trivial@nongnu.org \
/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.