From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7742 invoked by alias); 5 May 2005 16:26:16 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 7177 invoked from network); 5 May 2005 16:25:47 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sourceware.org with SMTP; 5 May 2005 16:25:47 -0000 Received: from drow by nevyn.them.org with local (Exim 4.50 #1 (Debian)) id 1DTjAW-0003qs-43 for ; Thu, 05 May 2005 12:25:44 -0400 Date: Thu, 05 May 2005 16:26:00 -0000 From: Daniel Jacobowitz To: gdb-patches@sources.redhat.com Subject: Re: [RFC] fullname attribute for GDB/MI stack frames Message-ID: <20050505162543.GA14746@nevyn.them.org> Mail-Followup-To: gdb-patches@sources.redhat.com References: <20050430191755.GF7009@nevyn.them.org> <20050501021945.GA19962@white> <20050505162233.GD31111@white> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050505162233.GD31111@white> User-Agent: Mutt/1.5.8i X-SW-Source: 2005-05/txt/msg00166.txt.bz2 On Thu, May 05, 2005 at 12:22:33PM -0400, Bob Rossi wrote: > > As far as i understand, it is acceptable to add new fields to a stable > > version of MI. It is the parsers responsibility to ignore MI fields that > > they are unfamiliar with. I also understand that it is acceptable to add > > new commands to an MI version. Making either of the 2 changes above does > > not effect the version number of the MI release (AFAIK). > > > > With that said, I'm not quite sure what model Andrew had in mind > > when releasing the MI versions. Here is 2 possibilities, > > > > Originally there is mi-. Once it becomes stable it is released as mi2-. > > mi2- is never touched again, accept for bug fixes. All development and > > new features is done on mi-. When mi- becomes stable again it is turned > > into mi3-. > > > > Originally there is mi-. Once it becomes stable it is released as mi2-. > > Any changes compatible with the MI2 protocol should be merged into the > > mi- and mi2- testcases. Changes that are not compatible with mi2 should > > be merged into mi-. When mi- becomes stable enough it could be moved > > into mi3-. > > > > I prefer the second model. I think it is more flexible and would allow > > for features to get into the MI protocol faster. > > Ping, any decision on this? I need to know if I should be modifing mi2 > testcases or just mi? I had no objection to your explanation. I thought you were just adding the regex and I was going to update the testcases? -- Daniel Jacobowitz CodeSourcery, LLC