[libvirt] Deprecating stuff for 4.2 (was: [Qemu-devel] Exposing feature deprecation to machine clients)
Vladimir Sementsov-Ogievskiy <vsementsov(a)virtuozzo.com> writes:
07.11.2019 21:52, Philippe Mathieu-Daudé wrote:
[...]
> Pre-release period, time to deprecate some stuffs :)
>
> How should we proceed? Do you have something in mind?
>
> There are older threads about this. Should we start a new thread? Gather the
different ideas on the Wiki?
>
> (Obviously you are not the one responsible of this topic, you just happen to be the
last one worried about it on the list).
>
> Regards,
>
> Phil.
4.2.0-rc0 has been tagged, i.e. we're in hard freeze already. Only bug
fixes are accepted during hard freeze. We've occasionally bent this
rule after -rc0 for borderline cases, e.g. to tweak a new external
interface before the release calcifies it. Making a case for bending
the rules becomes harder with each -rc.
Ideally, we'd double-check new interfaces for gaffes before a release,
and whether old interfaces that have been replaced now should be
deprecated. There's rarely time for that, and pretty much never for
releases right after KVM Forum.
So no, I don't have anything in mind for 4.2.
We intend to tag -rc1 next Tuesday. To make that deadline, we'd need
patches, not just ideas.
Hi!
I wanted to resend, but faced some problems, and understand that I can't do it in
time before soft-freeze..
But you say, that we can deprecate something even after hard-freeze?
See above.
Ok, the problem that I faced, is that deprecation warnings breaks
some iotests.. What can we do?
1. Update iotests...
1.1 Just update iotests outputs to show warnings. Then, in next release cycle, update
iotests, to not use deprecated things
Sounds workable to me, but I'm not the maintainer.
or
1.2 Update iotests to not use deprecated things.. Not appropriate for hard freeze.
Unnecessarily risky compared to 1.1.
or
2. Commit deprecations without warnings.. But how do people find out about this?
Not nice.
We do it for QMP, but only because we still lack the means to warn
there.
Next, what exactly to deprecate? As I understand, we can't
deprecate drive-mirror now?
So I propose to:
1. deprecate drive-backup
2. add optional filter-node-name parameter to drive-mirror, to correspond to commit and
mirror
3. deprecate that filter-node-name is optional for commit and mirror.
To have a chance there, we need patches a.s.a.p.