From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27502 invoked by alias); 12 May 2006 14:02:39 -0000 Received: (qmail 27494 invoked by uid 22791); 12 May 2006 14:02:39 -0000 X-Spam-Check-By: sourceware.org Received: from eastrmmtao06.cox.net (HELO eastrmmtao06.cox.net) (68.230.240.33) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 12 May 2006 14:02:35 +0000 Received: from localhost.localdomain ([68.9.66.48]) by eastrmmtao06.cox.net (InterMail vM.6.01.06.01 201-2131-130-101-20060113) with ESMTP id <20060512140232.VKGE16402.eastrmmtao06.cox.net@localhost.localdomain> for ; Fri, 12 May 2006 10:02:32 -0400 Received: from bob by localhost.localdomain with local (Exim 4.52) id 1FeYEc-0005ip-3C for gdb-patches@sourceware.org; Fri, 12 May 2006 10:03:14 -0400 Date: Fri, 12 May 2006 14:10:00 -0000 From: Bob Rossi To: gdb-patches@sourceware.org Subject: Re: CLI and GDB/MI documentation patch Message-ID: <20060512140313.GF26655@brasko.net> References: <20060512011730.GA26655@brasko.net> <20060512124940.GB3860@nevyn.them.org> <20060512135802.GA6472@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060512135802.GA6472@nevyn.them.org> User-Agent: Mutt/1.5.9i 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/msg00242.txt.bz2 On Fri, May 12, 2006 at 09:58:02AM -0400, Daniel Jacobowitz wrote: > On Fri, May 12, 2006 at 04:53:28PM +0300, Eli Zaretskii wrote: > > In general, if some external package needs to support multiple GDB > > versions, their authors will need to look in the manuals of those > > older versions. > > Is there somewhere appropriate to record this sort of change, in > more detail than would fit in NEWS, if you think that the manual is not > the place for it? This sort of information is incredibly useful when > e.g. upgrading; there's no easy way for users to "diff" the manual. I propose putting in the manual all of the changes since the last version of MI, in a new section. So this way, users can easily understand what changed. If they are upgrading from an older version, they can look at that manual.