This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: GDB/MI snapshots between major release's
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