From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13971 invoked by alias); 4 Oct 2004 13:19:09 -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 13960 invoked from network); 4 Oct 2004 13:19:07 -0000 Received: from unknown (HELO lakermmtao09.cox.net) (68.230.240.30) by sourceware.org with SMTP; 4 Oct 2004 13:19:07 -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 <20041004131907.VLYK4976.lakermmtao09.cox.net@white>; Mon, 4 Oct 2004 09:19:07 -0400 Received: from bob by white with local (Exim 3.35 #1 (Debian)) id 1CESk6-00027d-00; Mon, 04 Oct 2004 09:19:06 -0400 Date: Mon, 04 Oct 2004 14:59:00 -0000 From: Bob Rossi To: Eli Zaretskii Cc: gdb@sources.redhat.com Subject: Re: GDB/MI snapshots between major release's Message-ID: <20041004131906.GB8121@white> Mail-Followup-To: Eli Zaretskii , gdb@sources.redhat.com References: <20041003163918.GB7030@white> <01c4a9ce$Blat.v2.2.2$d01969a0@zahav.net.il> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01c4a9ce$Blat.v2.2.2$d01969a0@zahav.net.il> User-Agent: Mutt/1.3.28i X-SW-Source: 2004-10/txt/msg00043.txt.bz2 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. 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