Re: GDB/MI snapshots between major release's

[Bob Rossi <bob at brasko dot net>]

On Mon, Oct 04, 2004 at 05:33:54PM +0200, Mark Kettenis wrote:
>    Date: Mon, 4 Oct 2004 09:19:06 -0400
>    From: Bob Rossi <bob@brasko.net>
> 
>    On Mon, Oct 04, 2004 at 06:57:35AM +0200, Eli Zaretskii wrote:
>    > > Date: Sun, 3 Oct 2004 12:39:18 -0400
>    > > From: Bob Rossi <bob@brasko.net>
>    > > 
>    > > Here is my take, since Eli stated that MI is backwards compatible, I
>    > > think the version number should be bumped right before the release.
>    > 
>    > The MI number should be bumped when an incompatibility is introduced
>    > on purpose, i.e. at the very moment when we decide to start a new MI
>    > version.
> 
>    OK, at first I don't like this idea for several reasons. It seems to me
>    that with this approach you could end up releasing GDB 6.0 with MI
>    version 1 and GDB 6.1 with MI version 5. Meaning that there could be
>    several versions of MI revisions between one major release.
> 
> Of course not.  We'd bump the MI version on the first incompatible
> change after a release, but we wouldn't bump it again until after the
> next release.  It's highly unlikely that we'd have to bump the MI
> version for a patch release, except when there's a need to fix a
> critical bug in the MI interface.  Yes, GDB 6.1 could be released with
> MI version 2, 6.2, 6.3 with MI version 3, GDB 6.4 with MI version 4
> and GDB 7.0 with MI version 5.  But since we aim for stability of the
> MI interface, even that would be unlikely.

OK, this is good news. So basically, even thought the MI version is
bumped it is still not official. Meaning, at that point, if I updated my
front end to be compatible with the new MI protocol version, there could
still be another incompatible change before the release. Meaning, I
would have to wait for the release to get the use out of that new
version. This is OK with me as long as,

   - I can have the --mi-protocols command line switch that tells me 
   what version of GDB/MI protocol is officially supported.

   - This command line switch only has MI protocols added to it when the 
   MI protocols become official ( for a release )

>    It seems that you would have to run the testsuite on every incompatible
>    change that the MI protocol goes through, including several for only one
>    release. Also, a front end would have to understand all of these
>    revisions in hopes of working with the most recent GDB (CVS snapshots).
> 
> In the end there will be no hope for a frontend to be compatible with
> each and every CVS snapshot that's made.  

Agreed, and I am learning that it would be wise to stay away from this
idea. It seems better that the front end understand somehow that the
current version is not official (CVS snapshot) and it should work with
the last official release.

> If we go through the
> development process we might add several features between two
> releases.  All we can guarantee is that once we make an official GDB
> release with a certain version of MI, that version of MI will never
> change again, and will be supported in the next X GDB releases.

This is perfect. Is this your view or the view of GDB/MI's maintainers
also?

Thanks,
Bob Rossi