Luiz Capitulino <lcapitul...@redhat.com> writes: > On Fri, 09 Jul 2010 15:24:48 +0200 > Markus Armbruster <arm...@redhat.com> wrote: > >> Luiz Capitulino <lcapitul...@redhat.com> writes: >> >> > On Fri, 09 Jul 2010 10:44:32 +0200 >> > Markus Armbruster <arm...@redhat.com> wrote: >> > >> >> Luiz Capitulino <lcapitul...@redhat.com> writes: >> >> >> >> > This helps ensuring two things: >> >> > >> >> > 1. An initial warning on client writers playing with current QMP >> >> > 2. Clients using unstable QMP will break when we declare QMP stable and >> >> > drop that argument >> [...] >> >> Is it really necessary to break all existing users of QMP? >> > >> > The protocol is going to change, they will break anyway. >> >> Then why break them now in addition to then? > > Existing clients? Yes, you have a point. Although our only known existing > client atm is libvirt. > >> >> What are we trying to accomplish by that? >> > >> > QMP in 0.13 is in usable state. I fear that people will start using it >> > without noting/caring the protocol is going to be different in 0.14. >> > >> > The removal of this flag in 0.14 (assuming we'll have a stable QMP by >> > then), >> > makes clients break right away, instead of unexpected breaking in subtle >> > ways. >> > >> > This makes it easy to identify what's wrong and the message will be: you >> > should review your QMP usage, because the protocol has changed. >> > >> > That said, I'm not that strong about this particular solution. What I >> > really >> > would like to have is an easy way to identify old clients using a now >> > stable version of QMP. >> >> If we want obsolete clients to break when we release 0.14, then let's >> break them then. No need to break not-yet-obsolete clients now. >> Especially not in a way that unbreaks them in 0.14, when they are >> *really* obsolete. > > I don't think we have that many clients today, the only known one is > libvirt. So, this patch takes only new clients in consideration, those > who might start using QMP in 0.13. > > Again, I'm ok with a different solution. I just want to go beyond a README > file > warning. > > What about a "warning" key in the greeting message? Like: > > "warning": "QMP is unstable, it will break soon!" > > Not sure it matters as our greeting message is a bit too verbose, but > seems better than nothing.
Works for me.
