Daniel P. Berrangé <berra...@redhat.com> writes: > On Thu, Jun 06, 2024 at 01:22:14PM -0400, John Snow wrote: >> On Thu, Jun 6, 2024 at 6:25 AM Victor Toso <victort...@redhat.com> wrote: >> > On Wed, Jun 05, 2024 at 11:47:53AM GMT, John Snow wrote: >> Importantly, old versions of the schema aren't contained *entirely* within >> the schema. Here's a timeline: >> >> v0.12.0: QMP first introduced. Events are hardcoded, commands are defined >> in qemu-monitor.hx. query commands are hard-coded in monitor.c. >> v0.14.0: qemu-monitor.hx is forked into qmp-commands.hx and hmp-commands.hx >> v1.0: First version which features qapi-schema.json; all query commands are >> qapified but most other commands are not. >> v1.1.0: A very large chunk of commands are QAPIfied. >> v1.3.0: Most commands are now QAPIfied, but there are 2-3 remaining. >> v2.1.0: events are now fully qapified; most are now defined in >> qapi/events.json >> v2.8.0: The remaining commands are fully qapified; qmp-commands.hx is >> removed. > > v2.8.0 was in Dec 2016 - 7+1/2 years ago. > > libvirt's min QEMU version is 4.2.0 - Dec 2019 > > Ther are non-libvirt consumers of QEMU, but for them, do we think it is > reasonable for a consumer of QAPI *today*, to care about a QEMU version > from almost 8 years ago ? > > IOW, I wonder if the most pragammatic answer to this problem is to simply > entirely ignore the problems prior to 2.8.0 - accept that the versioning > is inaccurate/incomplete for versions before 2.8.0
I'm in favour. However, I'd prefer honest "Since: at least 2.8.0" to "Since: <untrustworthy but irrelevant version <= 2.8.0>".
