Re: GDB/MI snapshots between major release's

[Mark Kettenis <kettenis@gnu.org>]

   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.

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

Seems like your problem is that various Linux distribution come with
their own hacked versions of GDB that do not correspond to an official
release.  Those distributions are not doing proper release management.
You should blame them, not the GDB developers.  Or you should tell
your users to use an OS with proper release management like *BSD ;-).

   I have a suggestion, although I don't know how much it helps. I propose
   that GDB changes the MI version once for every major release. It
   documents the changes so that front end developers can update there
   protocols appropriately from the last release. Finally, if the user
   starts GDB like --interpreter=mi, it would actually give the current
   development version of MI which is unsupported officially. Then the
   front ends would have to query GDB for the officially supported released
   protocols, and start GDB with the newest one they support.

   Could this work well with the GDB team?

No.

Mark