From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17308 invoked by alias); 4 Oct 2004 15:34:26 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 17288 invoked from network); 4 Oct 2004 15:34:23 -0000 Received: from unknown (HELO server7.nfra.nl) (192.87.1.57) by sourceware.org with SMTP; 4 Oct 2004 15:34:23 -0000 Received: from juw15.nfra.nl [10.87.8.15] by server7.nfra.nl; Mon, 04 Oct 2004 17:34:01 +0200 Received: from juw15.nfra.nl (localhost [127.0.0.1]) by juw15.nfra.nl (8.12.2+Sun/8.11.1) with ESMTP id i94FXtCu014651; Mon, 4 Oct 2004 17:33:55 +0200 (CEST) Received: (from kettenis@localhost) by juw15.nfra.nl (8.12.2+Sun/8.12.2/Submit) id i94FXsPa014648; Mon, 4 Oct 2004 17:33:54 +0200 (CEST) Date: Mon, 04 Oct 2004 15:49:00 -0000 Message-Id: <200410041533.i94FXsPa014648@juw15.nfra.nl> From: Mark Kettenis To: bob@brasko.net CC: eliz@gnu.org, gdb@sources.redhat.com In-reply-to: <20041004131906.GB8121@white> (message from Bob Rossi on Mon, 4 Oct 2004 09:19:06 -0400) Subject: Re: GDB/MI snapshots between major release's References: <20041003163918.GB7030@white> <01c4a9ce$Blat.v2.2.2$d01969a0@zahav.net.il> <20041004131906.GB8121@white> X-SW-Source: 2004-10/txt/msg00045.txt.bz2 Date: Mon, 4 Oct 2004 09:19:06 -0400 From: Bob Rossi 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 > > > > 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