From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7985 invoked by alias); 4 Oct 2004 15:58:08 -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 7975 invoked from network); 4 Oct 2004 15:58:06 -0000 Received: from unknown (HELO lakermmtao09.cox.net) (68.230.240.30) by sourceware.org with SMTP; 4 Oct 2004 15:58:06 -0000 Received: from white ([68.9.64.121]) by lakermmtao09.cox.net (InterMail vM.6.01.03.04 201-2131-111-106-20040729) with ESMTP id <20041004155806.BRPP6584.lakermmtao09.cox.net@white>; Mon, 4 Oct 2004 11:58:06 -0400 Received: from bob by white with local (Exim 3.35 #1 (Debian)) id 1CEVDx-0002DG-00; Mon, 04 Oct 2004 11:58:05 -0400 Date: Mon, 04 Oct 2004 16:04:00 -0000 From: Bob Rossi To: Mark Kettenis Cc: eliz@gnu.org, gdb@sources.redhat.com Subject: Re: GDB/MI snapshots between major release's Message-ID: <20041004155805.GF8121@white> Mail-Followup-To: Mark Kettenis , eliz@gnu.org, gdb@sources.redhat.com References: <20041003163918.GB7030@white> <01c4a9ce$Blat.v2.2.2$d01969a0@zahav.net.il> <20041004131906.GB8121@white> <200410041533.i94FXsPa014648@juw15.nfra.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200410041533.i94FXsPa014648@juw15.nfra.nl> User-Agent: Mutt/1.3.28i X-SW-Source: 2004-10/txt/msg00047.txt.bz2 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 > > 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. 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