Re: [patch rfa:doco rfc:NEWS] mi1 -> mi2; rm mi0

[Andrew Cagney <ac131313@redhat.com>]

> Hi, all...
> 
> The changes from mi0 to mi1 were pretty trivial.  So clients (in my case Project Builder) can fairly easily accommodate the removal of the mi0 interpreter.  I am not suggesting that we reinstate that.
> 
> However, the mi2 is shaping up to be a pretty big change (among other things, command results are differently reported in toto, as well as some command results changing format.)  Converting PB from mi1 to mi2 is going to be a lot of work.   And because of its nature, there is no a priori way to tell what all the clients are - and not all the clients will closely read the gdb-patches mailing list...

mi2 is bug fixes on mi1.  However, at the same time it is gaining some 
of the missing functionality.  Its just that more bugs and more missing 
functionality are being worked on.  To put it simply, about time!

cf the patch to pr gdb/672 where the output was straight bogus (it 
contained the equivalent of {name="foo", name="bar", name="baz"}.  JeffJ 
has been asked to preserve the old (broken) behavior.  I should note it 
was very tempting to not make this request since the old behavior was 
broken and should have been bug-reported and fixed long long ago.

> Because of this, I am a little nervous at the easy way we are talking about deleting older versions of the mi.  I think it is our responsibility to careful, and only release versions of the mi that we want to support, not the clients of the mi's responsibility to change their code every time we decide we are tired of supporting the test cases from one of the other versions we have previously promulgated...  The mi loses much of its appeal if it means you are going to have to occasionally rework parts of your client that already work just fine, or suffer permanent fork-hood for your gdb.

I was ment to delete mi0 something like a year ago.  I'm running a 
little late on that one :-)

> I agree with Daniel that we should hold off on declaring a real mi2 till we have something we are willing to support long term.   And for the mi to be useful, I think we need to stick to only putting out named versions that we are willing to support.

Part of the nature of GDB is that it is constantly evolving.  MI is 
going to be (like it or not) part of that evolution.  Each new GDB 
release will see enhancements and bug fixes and MI uses will need to be 
accomodating to that.

In return for this accomodation GDB are trying to preserve a given MI 
interface for at least two release cycles.  Part of is the very strong 
emphasis on testcases and documentation.  If you feel that things are 
lacking in this area then, perhaphs something to contribute to, is the 
documentation and testing infrastructure for MI (did the apple droppings 
contain any new tests?).

Over time, the MI interface should also stablize.

Andrew