Re: Does our interface compatibility promise cover defaults?

[Paolo Bonzini <pbonzini@redhat.com>]

On 11/11/25 09:32, Markus Armbruster wrote:
>>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?

In some sense, versioned machine types are an example "changing the 
defaults without notice": almost every release of QEMU changes the 
default values for -M pc and -M virt.

But then, while we change the defaults, we provide a way to access the 
old defaults and only remove the old machine types with advance 
notification.

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

Generally speaking I'd say so.  I don't speak much crypto, but the 
latest commit to deprecated.rst (commit d58f9b20c71, "crypto: deprecate 
use of external dh-params.pem file", 2025-11-03) looks like a change of 
defaults.

Paolo

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