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