> The deprecation policy is primarily intended for notifying of changes > to QEMU's stable interfaces ( CLI, HMP, QMP) which affect behaviour > and usage of QEMU at runtime & are liable to break apps managing > QEMU. > > Changes to build time options have no strong reason to be subjected to > the deprecation process.
This sounds reasonable to me. But: Should our deprecation policy be clearer on what is subject to our deprecation procedure, and what is not? Regards, Aleksandar > If we remove an option at build time the effect > is noticed immediately and the solution is straightforward (stop passing > the option). We have added / removed configure options at will with little > negative feedback historically. We'll have far biggest changes coming to > the build system in future too, with the introduction of meson. > > I don't think we want to constrain & complicate our work in modernizing > the build system by declaring that any changes to it must go through > deprecation. > > Regards, > Daniel > -- > |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| > |: https://libvirt.org -o- https://fstop138.berrange.com :| > |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| >
