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

[Jim Ingham <jingham@apple.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...

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 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.

Jim

> On Mon, Sep 30, 2002 at 11:03:55AM -0400, Andrew Cagney wrote:
>>
>>>>>
>>>>> Are you planning to revert mi1 then?
>>>
>>>>
>>>> Que?
>>>
>>>
>>> "mi2" changes have been sneaking in.  Are you planning to revert 
>>> them -
>>> create an "mi1" which matches what mi1 actually was.
>>
>> It's a bit late for that.  Someone should audit the changes made so 
>> far
>> and identify which caused syntax changes and update accordingly.  
>> Fixes
>> could, perhaphs be pushed into 5.3 (but I don't have the time).
>>
>>> Otherwise, where is the line drawn to mark the interface version as
>>> final?  It seems to me that the default shouldn't be evolving, that
>>> -i=mi should default to a fixed point until the next version is
>>> running.
>>
>> I think a line is drawn when each release is made.  I'd expect an MI
>> client to explicitly specify -i=miN (where N was formally released)
>> rather than trust -i=mi.
>>
>> However, should the HEAD hold off on recognizing -i=mi2 until the next
>> branch is cut?  On the HEAD, -i=mi evolves by definition.  However,
>> -i=mi2 is evolving as well :-(
>
> That'd be best I think.  I think that -i=mi2 specifies a fixed standard
> and we don't have one yet; so how about -i=mi being different from
> -i=mi1, but not adding -i=mi2 until we're ready to fix the interface?
>
> -- 
> Daniel Jacobowitz
> MontaVista Software                         Debian GNU/Linux Developer
>
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-
Jim Ingham                                                           
jingham@apple.com
Developer Tools - gdb