Re: GDB/MI snapshots between major release's

[Fabian Cenedese <Cenedese at indel dot ch>]

At 17:27 04.10.2004 -0400, Bob Rossi wrote:
>On Mon, Oct 04, 2004 at 01:53:57PM -0700, Felix Lee wrote:
>> why would that happen?  I expect 'create a new MI version' to be
>> basically an atomic change.  like, someone experiments with MI11
>> on a branch, then merges it into the trunk when it's stable and
>> tests reasonable cleanly.
>
>This is frustrating to me, does anyone understand the problem that I am
>describing? Maybe it could be said in a better way.

I do, though I haven't a solution either.

>Basically, a given GDB (from an official release) supports several MI protocols.
>A given GDB from a CVS snapshot supports several MI protocols and 1
>unsupported protocol.
>
>The 1 unsupported protocol is the problem. 

One thing that could be added is that -i mi doesn't mean the last one (like mi2 now)
but the last official one. So if there will be a mi3 in progress mi will still select mi2.
Like that you will always be using the last stable protocol. And others can work
with the development version by calling -i mi3. But that won't solve your problem
of knowing what mi version the last stable really is.

>During development, the first incompatible change forces the MI version
>number to be bumped. Every incompatible change after that does not
>effect the MI version number. Only after the release can the number be
>bumped again (as far as I understand it).

The release would be the point where -i mi changes from mi2 to mi3.

>I am saying that I need to know if GDB is communicating with one of
>these development MI protocols, because I want to use the last official
>MI protocol, not a development MI protocol.

To take your example:

gdb --mi-protocols
 mi1
*mi2
 mi3

which means that mi2 is the default (and therefore last stable) mi version. Like
that you get all the necessary info about available and stable versions at once.

bye  Fabi