Re: GDB/MI snapshots between major release's

[Bob Rossi <bob at brasko dot 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.
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).

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?

Thanks,
Bob Rossi