On 10/04/2018 01:03 PM, Andrea Bolognani wrote: > 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 :) This was my reasoning too. We have to have run time warnings. Not all languages are compiled. Even though I have no statistics, I am confident to say that oVirt and OpenStack are our biggest consumers and they use python bindings. Compile time warnings won't help us there, rather the opposite - put pressure on us when writing them. > > 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. > /me grabbing some popcorn and soda O:-) So this was going to be my question. What is the end goal we are trying to achieve? If it is to advertise we have a better API to do the job, we can document it - just like we are doing so far. Also the term "better API" depends on individual use case heavily. If I have a small, one host virtualization solution, and I know nobody else is starting up/shutting down domains, I might use virDomainGetNames() just fine. Worse, if I have a working solution and I upgrade libvirt I'll start seeing warning all of a sudden. This kind of breaks our promise of stability. If the goal is to make mgmt apps switch to APIs we consider better, then we definitely need runtime warnings. I don't see how apps written in dynamic, not compiled languages can detect they're using deprecated API without running themselves. And surely nor developers, nor QEs have 100% code coverage tests. And for dropping functionality - we can not do that. Period. Michal -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
