From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23985 invoked by alias); 13 May 2006 09:07:31 -0000 Received: (qmail 23976 invoked by uid 22791); 13 May 2006 09:07:30 -0000 X-Spam-Check-By: sourceware.org Received: from viper.snap.net.nz (HELO viper.snap.net.nz) (202.37.101.8) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 13 May 2006 09:07:13 +0000 Received: from kahikatea.snap.net.nz (p425-tnt1.snap.net.nz [202.124.111.171]) by viper.snap.net.nz (Postfix) with ESMTP id 784E47575B2; Sat, 13 May 2006 21:07:11 +1200 (NZST) Received: by kahikatea.snap.net.nz (Postfix, from userid 500) id 84A741D3551; Sun, 14 May 2006 21:06:57 +1200 (NZST) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17510.62256.102468.268003@kahikatea.snap.net.nz> Date: Sat, 13 May 2006 09:13:00 -0000 To: Bob Rossi Cc: Eli Zaretskii , ghost@cs.msu.su, gdb-patches@sources.redhat.com Subject: Re: CLI and GDB/MI documentation patch In-Reply-To: <20060512221531.GA1741@brasko.net> References: <17509.54397.736467.479414@kahikatea.snap.net.nz> <17509.943.40875.198555@farnswood.snap.net.nz> <20060512221531.GA1741@brasko.net> X-Mailer: VM 7.19 under Emacs 22.0.50.11 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-05/txt/msg00279.txt.bz2 > > Because if people write a front end that relies on a feature then > > understanably they are upset when it is changed or removed, just as I was > > when it appeared that annotations would be removed. The one advantage of > > Emacs long release cycle is that it gives you more time to get everything > > right before its released. GDB goes out about every six months along > > with an expectation that its behaviour will some level of maintenance. > > I agree with you completly. What if we released mi3 with the > next release of GDB. We could remove the direct CLI commands then. I > think there would be some advantages to releasing mi3 anyways. AFAICS the only changes to MI since 6.4 have been to add the fullname field to breakpoint related commands and to generate an error record for directly entered CLI commands. I think we only need to bump the number when an incompatible change change is made that will break existing front ends. I also think it will prove too difficult to maintain functionality for old levels in general (mi0 or mi1 might be an exception) but clearly new front ends will be able to work with more than one level if they want (old ones will break with the new level). We did start to talk about what changes could be made within one level: new commands, extra fields etc which I think we need to document so that developers know what to expect. I think at some stage we should also document our thoughts changing MI level. -- Nick http://www.inet.net.nz/~nickrob