qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Markus Armbruster <armbru@redhat.com>
To: qemu-devel@nongnu.org
Cc: "Kevin Wolf" <kwolf@redhat.com>,
	"Daniel P. Berrangé" <berrange@redhat.com>,
	"Peter Maydell" <peter.maydell@linaro.org>,
	"Alex Bennée" <alex.bennee@linaro.org>,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	devel@lists.libvirt.org
Subject: Does our interface compatibility promise cover defaults?
Date: Tue, 11 Nov 2025 09:32:50 +0100	[thread overview]
Message-ID: <875xbhdl59.fsf@pond.sub.org> (raw)

From about/deprecated.rst:

    In general features are intended to be supported indefinitely once
    introduced into QEMU. In the event that a feature needs to be removed,
    it will be listed in this section. The feature will remain functional for the
    release in which it was deprecated and one further release. After these two
    releases, the feature is liable to be removed. Deprecated features may also
    generate warnings on the console when QEMU starts up, or if activated via a
    monitor command, however, this is not a mandatory requirement.

This obviously applies to syntax and semantics of our external
interface.

Does it apply to default values there?

If no: does this mean we can change defaults without notice?

If yes: does this mean any change of defaults needs notice in
about/deprecated.rst and the grace period?

Note that changing a default is a silent change, like changing semantics
/ behavior, unlike changing syntax.



             reply	other threads:[~2025-11-11  8:33 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-11  8:32 Markus Armbruster [this message]
2025-11-11  8:58 ` Does our interface compatibility promise cover defaults? Paolo Bonzini
2025-11-11  9:25   ` Daniel P. Berrangé

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=875xbhdl59.fsf@pond.sub.org \
    --to=armbru@redhat.com \
    --cc=alex.bennee@linaro.org \
    --cc=berrange@redhat.com \
    --cc=devel@lists.libvirt.org \
    --cc=kwolf@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).