From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9098 invoked by alias); 10 Feb 2006 12:03:32 -0000 Received: (qmail 9088 invoked by uid 22791); 10 Feb 2006 12:03:31 -0000 X-Spam-Check-By: sourceware.org Received: from zigzag.lvk.cs.msu.su (HELO zigzag.lvk.cs.msu.su) (158.250.17.23) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 10 Feb 2006 12:03:30 +0000 Received: from Debian-exim by zigzag.lvk.cs.msu.su with spam-scanned (Exim 4.50) id 1F7Wzn-0006JC-Ck for gdb@sources.redhat.com; Fri, 10 Feb 2006 15:03:28 +0300 Received: from zigzag.lvk.cs.msu.su ([158.250.17.23]) by zigzag.lvk.cs.msu.su with esmtp (Exim 4.50) id 1F7WzR-0006IJ-Mc; Fri, 10 Feb 2006 15:03:05 +0300 From: Vladimir Prus To: Bob Rossi Subject: Documenting MI stability (Was: MI -break-info command issues) Date: Fri, 10 Feb 2006 12:03:00 -0000 User-Agent: KMail/1.7.2 Cc: gdb@sources.redhat.com References: <20060127161340.GC30826@brasko.net> In-Reply-To: <20060127161340.GC30826@brasko.net> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200602101503.03603.ghost@cs.msu.su> Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-02/txt/msg00076.txt.bz2 On Friday 27 January 2006 19:13, Bob Rossi wrote: > On Fri, Jan 27, 2006 at 07:09:56PM +0300, Vladimir Prus wrote: > > Daniel Jacobowitz wrote: > > >> The problem with existing frontends can probably be solved by posting > > >> a prominent message to mailing list whenever MI output is going to > > >> change. Or using versioning. > > > > > > This has been discussed before plenty of times. We will make > > > incompatible changes to MI from time to time; but IMO that doesn't > > > justify making _unnecessary_ incompatible changes. > > > > > > Like Bob, I wouldn't have added the fields. But since they are > > > present, I see no reason to remove them. > > > > Ok, understood. It would be good, though, if MI docs contained some > > introduction chapter that would state this policy. That'd prevented this > > thread from ever starting. > > Hi Volodya, > > It would be great if you could come up with some text that described the > problem. We could improve it here, and then add it to the manual. Hi Bob, What about this: = Stability = While MI format is still evoling, all changes to it will be backward compatible. That is, only new fields will be added, and all existing fields will be retained. This means that replies to certain command might contain information that is not strictly necessary for machine interface, and a present for historical reasons only. Rationale: There are many MI frontends around, and their developers don't necessary follow MI changes and read the mailing list, so it's better to live with a few extra fields than risk breaking existing code. You probably can phrase this better, but something to this effect will be a good addition to MI manual. And it would be great to have some guidelines when MI compatibility *can* be broken -- I don't know those guidelines so can't write anything about it. Thanks, Volodya