On Thu, 2018-10-04 at 13:16 +0200, Michal Privoznik wrote: > On 10/04/2018 01:03 PM, Andrea Bolognani wrote: > > 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. Until the time you give access to your host to another user, and suddenly your scripts will fail 10% of the time for no obvious reason ;) Using the proper API might be more work upfront, but it will pay off in the long run. > 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 functionality keeps working, then getting a bunch of warnings in the process will definitely not break any stability promise. And if reporting warnings breaks functionality, then we need to find a different way to report them because applications no longer working after a libvirt update is simply unacceptable. > And for dropping functionality - we can not do that. Period. It's *us* who decided that's the case, so it's up to *us* to uphold that decision. Or, you know, revert it :) I'm not saying that we should start dropping random features out of the blue without any rationale, but if we start formally deprecating functionality that we deem problematic and at the same time communicate clearly to both developers and users such functionality will be removed upstream after, say, three years worth of releases, then I see absolutely no problem with that. GTK+ does it, Qt does it; and I'm willing to bet there are more applications linking against either of them than there are linking against libvirt. -- Andrea Bolognani / Red Hat / Virtualization -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
