Re: Historical QMP schema

[Markus Armbruster <armbru@redhat.com>]

Daniel P. Berrangé <berrange@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 <victortoso@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>".