From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20056 invoked by alias); 8 Oct 2004 10:45:55 -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 20048 invoked from network); 8 Oct 2004 10:45:54 -0000 Received: from unknown (HELO legolas.inter.net.il) (192.114.186.24) by sourceware.org with SMTP; 8 Oct 2004 10:45:54 -0000 Received: from zaretski (pns03-208-187.inter.net.il [80.230.208.187]) by legolas.inter.net.il (MOS 3.5.3-GR) with ESMTP id CTV25789 (AUTH halo1); Fri, 8 Oct 2004 12:45:48 +0200 (IST) Date: Fri, 08 Oct 2004 12:05:00 -0000 From: "Eli Zaretskii" To: Joel Brobecker Message-ID: <01c4ad23$Blat.v2.2.2$a5eab6e0@zahav.net.il> Content-Transfer-Encoding: 7BIT Content-Type: text/plain; charset=ISO-8859-1 CC: dk@artimi.com, cagney@gnu.org, gdb@sources.redhat.com In-reply-to: <20041007180121.GL1282@gnat.com> (message from Joel Brobecker on Thu, 7 Oct 2004 11:01:21 -0700) Subject: Re: Discussion: Formalizing the deprecation process in GDB Reply-to: Eli Zaretskii References: <416562C9.90801@gnu.org> <20041007180121.GL1282@gnat.com> X-SW-Source: 2004-10/txt/msg00249.txt.bz2 > Date: Thu, 7 Oct 2004 11:01:21 -0700 > From: Joel Brobecker > Cc: 'Andrew Cagney' , 'Eli Zaretskii' , > gdb@sources.redhat.com > > I think that maintaining the list of deprecated features in a > separate document is going to be a large amount of work. GDB is > changing so fast. I don't see why it should be a large amount of work. Features are deprecated one at a time. Each time a feature gets deprecated, all we need is a short addition to the documentation stating (1) what is being deprecated, and (2) an example of the old code using the deprecated feature and a new code that should replace it. This list will grow as more features are deprecated and OTOH deprecated features that are deleted from the code will be deleted from this list. So where's that large amount of work you are afraid of? > It's simpler to put that information directly > in the code, and most of the time, the information is actually already > there. It maybe there, but there's no easy way to find it.