From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22341 invoked by alias); 6 Oct 2004 20:15: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 22333 invoked from network); 6 Oct 2004 20:15:26 -0000 Received: from unknown (HELO sire.mail.pas.earthlink.net) (207.217.120.182) by sourceware.org with SMTP; 6 Oct 2004 20:15:26 -0000 Received: from ip216-26-76-19.dsl.du.teleport.com ([216.26.76.19] helo=stray.canids) by sire.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 1CFIC5-00074J-00 for gdb@sources.redhat.com; Wed, 06 Oct 2004 13:15:25 -0700 Received: from stray.canids (localhost.localdomain [127.0.0.1]) by stray.canids (Postfix) with ESMTP id D6C6A502AB6 for ; Wed, 6 Oct 2004 13:15:24 -0700 (PDT) From: Felix Lee To: gdb@sources.redhat.com Subject: Re: Bumping MI protocol References: <20041006010100.GA10896@white> <20041006111436.GA11747@white> <01c4ab9d$Blat.v2.2.2$923860c0@zahav.net.il> <20041006165727.B1384502AB6@stray.canids> <20041006170238.GF12213@white> <20041006185407.A63A4502AB6@stray.canids> <20041006192526.GR12213@white> In-Reply-To: <20041006192526.GR12213@white> on Wed, 06 Oct 2004 15:25:26 EDT from Bob Rossi Date: Wed, 06 Oct 2004 21:04:00 -0000 Message-Id: <20041006201524.D6C6A502AB6@stray.canids> X-SW-Source: 2004-10/txt/msg00188.txt.bz2 Bob Rossi : > I am assuming that the MI output syntax will change. I expect it to. We > will need things in the future we do not know we need yet. sure. and when that time comes you can help decide whether to make the change in a way that's compatible with existing front-ends, or bump the version to indicate an incompatibility. if it's a nontrivial incompatibility, you can argue for calling it something other than MI, to avoid confusing a front-end that assumes all versions of MI have basically the same flavor. or you can argue for whatever seems best for the world at the time of that hypothetical future. there's not much point in spending a lot of effort guarding against unlikely futures when you have a lot of influence over the future. the only thing unmovable is the past, and that's already well-defined because the source code to every past version of gdb is freely available. --