On Wed, 2018-10-03 at 10:44 +0200, Erik Skultety wrote: > On Wed, Oct 03, 2018 at 09:13:00AM +0200, Michal Privoznik wrote: > > On 10/02/2018 05:38 PM, Pavel Hrdina wrote: > > > Definitely agree with Peter, having a runtime warning for issue that > > > you cannot change in runtime situation is IMHO wrong. Even though we > > > cannot remove any API the deprecation warning can be still useful > > > because it can suggest better API to use instead of the old one. > > > > So two of our biggest consumers use python bindings. I'm failing to see > > how a compile time warning would help here. The compile time warnings would cause bindings developers to find out APIs are being deprecated as they compile against newer libvirt the same way applications developers linking against the C library would; additionally, they could use that information as a motivation to deprecate *their* APIs in a language-appropriate manner. So, as mentioned elsewhere, I believe we should have ways to warn about deprecated features *both* at compile time and at runtime. > > In other words, if our goal is to make users switch to newer versions of > > functions then we might have to find a better solution (than compilte > > time warnings). Runtime warnings would work with python though. > > As John's pointed out in his reply, given our API contract, we're providing > devs of apps built on top of libvirt with certain guarantees, so it's fair to > assume they'd just ignore the warnings, since we can't break our contract and > their product keeps working anyway, so "why bother changing it", right? > Unfortunately, I feel it's a common practice not to change anything unless it > stops working and there might even be very legitimate reasons for such a > practice, like simply not enough man power. > Therefore I myself don't see any mass adoption/switch to the new preferred/safe > versions of our APIs any time soon. The only effect you'd IMHO achieve by having > runtime warnings is log pollution. Having said that, I don't have any better > ideas on how we could achieve this brave goal without using the obvious drastic > measures. Deprecation warnings can still help adoption: if tools start spewing them, users will notice and report bugs, eventually annoying developers into migrating to non-deprecated APIs :) Of course this works better for command line applications like virt-install than for GUI applications like virt-manager, but it's useful nonetheless. That said, in order to reap real benefits, deprecating features should go hand in hand with having a well-defined support policy that includes a timeline describing how, after a generous grace period, the functionality will actually be dropped altogether. -- Andrea Bolognani / Red Hat / Virtualization -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
