From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16947 invoked by alias); 4 Oct 2004 21:27:23 -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 16938 invoked from network); 4 Oct 2004 21:27:22 -0000 Received: from unknown (HELO lakermmtao06.cox.net) (68.230.240.33) by sourceware.org with SMTP; 4 Oct 2004 21:27:22 -0000 Received: from white ([68.9.64.121]) by lakermmtao06.cox.net (InterMail vM.6.01.03.04 201-2131-111-106-20040729) with ESMTP id <20041004212720.BIVI26180.lakermmtao06.cox.net@white>; Mon, 4 Oct 2004 17:27:20 -0400 Received: from bob by white with local (Exim 3.35 #1 (Debian)) id 1CEaMb-0002N6-00; Mon, 04 Oct 2004 17:27:21 -0400 Date: Mon, 04 Oct 2004 22:14:00 -0000 From: Bob Rossi To: Felix Lee Cc: gdb@sources.redhat.com Subject: Re: GDB/MI snapshots between major release's Message-ID: <20041004212721.GB8846@white> Mail-Followup-To: Felix Lee , gdb@sources.redhat.com References: <20041003163918.GB7030@white> <01c4a9ce$Blat.v2.2.2$d01969a0@zahav.net.il> <20041004131906.GB8121@white> <20041004145921.BAC77502AB6@stray.canids> <20041004154928.GE8121@white> <20041004160455.DD23A502AB6@stray.canids> <20041004164803.GG8121@white> <20041004181201.9A8E9502AB6@stray.canids> <20041004183145.GH8121@white> <20041004205357.1FBCD502AB6@stray.canids> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041004205357.1FBCD502AB6@stray.canids> User-Agent: Mutt/1.3.28i X-SW-Source: 2004-10/txt/msg00066.txt.bz2 On Mon, Oct 04, 2004 at 01:53:57PM -0700, Felix Lee wrote: > Bob Rossi : > > T1 GDB 7.0 has MI10 (official) > > T2 GDB 7.0-CVS has MI11 (unofficial, because of MI incompatible change X1 ) > > T3 GDB 7.0-CVS has MI11 (unofficial, because of MI incompatible change X2 ) > > T4 GDB 7.1 has MI11 (official) > > why would that happen? I expect 'create a new MI version' to be > basically an atomic change. like, someone experiments with MI11 > on a branch, then merges it into the trunk when it's stable and > tests reasonable cleanly. This is frustrating to me, does anyone understand the problem that I am describing? Maybe it could be said in a better way. Basically, a given GDB (from an official release) supports several MI protocols. A given GDB from a CVS snapshot supports several MI protocols and 1 unsupported protocol. The 1 unsupported protocol is the problem. During development, the first incompatible change forces the MI version number to be bumped. Every incompatible change after that does not effect the MI version number. Only after the release can the number be bumped again (as far as I understand it). Once the development GDB reaches maturity and becomes an official release, the development protocol becomes an official protocol. That new MI protocol could consist of say 10 incompatible changes with it's predecessor. Any CVS snapshot after the first incompatible change (version bump) and before the release will have GDB talking an MI protocol that is not supported by anyone. It is a development protocol that should never be used. I am saying that I need to know if GDB is communicating with one of these development MI protocols, because I want to use the last official MI protocol, not a development MI protocol. Do you understand? Thanks, Bob Rossi