Daniel P. Berrangé <berra...@redhat.com> writes: > On Wed, Oct 18, 2023 at 02:02:08PM +0200, Markus Armbruster wrote: >> Daniel P. Berrangé <berra...@redhat.com> writes: >> >> > On Wed, Oct 18, 2023 at 06:51:41AM -0400, Michael S. Tsirkin wrote: >> >> On Wed, Oct 18, 2023 at 12:36:10PM +0200, Markus Armbruster wrote: >> >> > > x- seems safer for management tool that doesn't know about "unstable" >> >> > > properties.. >> >> > >> >> > Easy, traditional, and unreliable :) >> >> >> >> > > But on the other hand, changing from x- to no-prefix is already >> >> > > done when the feature is stable, and thouse who use it already >> >> > > use the latest version of interface, so, removing the prefix is >> >> > > just extra work. >> >> > >> >> > Exactly. >> >> > >> >> >> >> I think "x-" is still better for command line use of properties - we >> >> don't have an API to mark things unstable there, do we? >> > >> > Personally I like to see "x-" prefix present *everywhere* there is >> > an unstable feature, and consider the need to rename when declaring >> > it stable to be good thing as it sets an easily identifiable line >> > in the sand and is self-evident to outside observers. >> > >> > The self-documenting nature of the "x-" prefer is what makes it most >> > compelling to me. A patch submission, or command line invokation or >> > an example QMP command, or a bug report, that exhibit an 'x-' prefix >> > are an immediate red flag to anyone who sees them. >> >> Except when it isn't, like in "x-origin". >> >> > If someone sees a QMP comamnd / a typical giant QEMU command line, >> > they are never going to go look at the QAPI schema to check whether >> > any feature used had an 'unstable' marker. The 'unstable' marker >> > might as well not exist in most cases. >> > >> > IOW, having the 'unstable' flag in the QAPI schema is great for machine >> > introspection, but it isn't a substitute for having an 'x-' prefix used >> > for the benefit of humans IMHO. >> >> I'm not sure there's disagreement. Quoting myself: >> >> The "x-" can remind humans "this is unstable" better than a feature >> flag can (for machines, it's the other way round). >> >> CLI and HMP are for humans. We continue to use "x-" there. >> >> QMP is for machines. The feature flag is the sole source of truth. >> Additional use of "x-" is fine, but not required. > > I guess we have different defintions of "for humans" in this context. > I consider QMP data still relevant for humans, because humans are > reviewing patches to libvirt that add usage of QMP features, or
There's a much more reliable way: 1. Require tests 2. Run them with -compat unstable-input=reject,unstable-output=hide Or unstable-input=crash if you don't trust or don't want to rely on your test harness. > triaging bug reports that include examples of usage, Here you can run the reproducer with -compat. > and in both > cases it is pretty relevant to make unstable features stand out to > the human via the x- prefix IMHO. Your point remains at least somewhat valid all the same.
