Eric Blake <ebl...@redhat.com> writes: > On 11/11/2015 03:19 AM, Markus Armbruster wrote: > >>>> Do we need this to make 2.5? >>> >>> It's true that the introspection will change (instead of seeing flat >>> optional members, you now have to chase down variants). But I don't >>> think it is pressing enough to rush into 2.5; the change is >>> backwards-compatible no matter when we do it, and introspection clients >>> are going to have to get used to the idea of chasing down different >>> paths to find all members of a struct (that is, if we don't change this >>> until 2.6, I'm sure it won't be the last case of introspection changing >>> while keeping QMP wire format back-compatible as formerly non-variant >>> fields become variant). >> >> We can mess with the schema as long as the QMP wire format stays >> compatible. >> >> With introspection, schema changes get exposed in QMP that weren't >> exposed before. Begs the question whether the ABI promise extends to >> the introspection value. >> >> I think we don't want to extend it, at least for now. In other words, >> we refuse to put additional constraints on schema changes to keep the >> introspection value stable. Makes introspection a bit harder to use. >> Not ideal, but better than committing to constraints we don't even fully >> understand, yet. >> >> I think we should spell this out introspection documentation. > > Sounds like I need to prep a doc patch for 2.5 then.
Yes, please! >> Our only example so far is converting between optional members and flat >> unions. Can we think of others? Hmm, you found one below. > > Converting from optional non-variant to variant, converting from string > to enum, converting from single type to alternate. Might be other > conversions, and the set of conversions for input types may differ from > those of output conversions. > >> Okay. I guess finding all the examples that matter may take a few >> development cycles. Perhaps we want to commit to some additional >> compatibility promises for introspection then. > > Maybe, but until clients are no longer worried about older clients, it > may be several years before taking advantage of whatever we later > document That's life. I fully expect the consumers of QMP introspection to get a few things wrong initially, requiring their users to upgrade to fixed versions. That's life, too. > (as it is, upstream libvirt is just now bumping minimum qemu > support up to 0.12 [thanks to RHEL 6] and discarding older qemu from > RHEL 5 - quite a few years behind upstream qemu 2.5, although it is > finding a lot of code in libvirt that is no longer necessary). In my opinion, attempting to support old versions of QEMU is a complete waste of resources unless you actually test them to stop the bit-rot. RHEL-6 0.12 is by now quite different from upstream 0.12. Unlike upstream 0.12, it's actually still relevant and useful today. I encourage you to identify relevant upstream and downstream versions, keep them tested, and drop support for the rest.
