From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31975 invoked by alias); 12 May 2006 18:55:44 -0000 Received: (qmail 31966 invoked by uid 22791); 12 May 2006 18:55:43 -0000 X-Spam-Check-By: sourceware.org Received: from nitzan.inter.net.il (HELO nitzan.inter.net.il) (192.114.186.20) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 12 May 2006 18:55:42 +0000 Received: from HOME-C4E4A596F7 (IGLD-80-230-33-4.inter.net.il [80.230.33.4]) by nitzan.inter.net.il (MOS 3.7.3-GA) with ESMTP id DIQ25873 (AUTH halo1); Fri, 12 May 2006 21:55:38 +0300 (IDT) Date: Fri, 12 May 2006 19:01:00 -0000 Message-Id: From: Eli Zaretskii To: gdb-patches@sourceware.org In-reply-to: <20060512183723.GA14434@nevyn.them.org> (message from Daniel Jacobowitz on Fri, 12 May 2006 14:37:23 -0400) Subject: Re: CLI and GDB/MI documentation patch Reply-to: Eli Zaretskii References: <20060512011730.GA26655@brasko.net> <20060512124940.GB3860@nevyn.them.org> <20060512135802.GA6472@nevyn.them.org> <20060512183723.GA14434@nevyn.them.org> X-IsSubscribed: yes 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/msg00255.txt.bz2 > Date: Fri, 12 May 2006 14:37:23 -0400 > From: Daniel Jacobowitz > > So, for someone who must support multiple versions of GDB, they would > have to read NEWS looking for changes, find the new behavior in the > current manual, and find the old (hopefully documented) behavior in the > old manual? No. I propose to have a special section devoted to incompatible changes in the remote protocol, and another one for incompatible changes in MI. Thus, no searching is necessary. As for old behavior, since the old versions of protocol/MI is already supported by the tools whose authors are the audience of these NEWS sections, I'd expect them to be well acquainted with the old behavior. So I don't think they will need to look for that. > Our current NEWS is basically bullet-points. That would definitely > need a change. Yes. We will have to subdivide into sections. > OK, reasonable enough, I suppose, although it seems > awkward when we know that many of the people reading this chapter in > the manual will be interested in precisely this historical information. > > Many shipping GDB frontends work on any version of GDB released in the > last several years and shipped by a large package distributor; that's a > lot of versions of GDB. I'm not sure the two cases are readily > comparable, though I realize that Emacs LISP programs probably have > similar issues. If you feel we should tell how to create a front end and/or a stub that supports several versions of GDB/MI or remote protocol, that's fine by me, but let's have sections whose focus is to provide tips to such programmers, not to tell the history of MI or the protocol's evolution. That's quite a different attitude than what Bob wrote.