From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3011 invoked by alias); 10 Oct 2014 07:38:23 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 2997 invoked by uid 89); 10 Oct 2014 07:38:22 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Fri, 10 Oct 2014 07:38:20 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s9A7bc5X020724 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 10 Oct 2014 03:37:38 -0400 Received: from localhost.localdomain (ovpn-112-17.ams2.redhat.com [10.36.112.17]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s9A7ba29005166; Fri, 10 Oct 2014 03:37:37 -0400 Message-ID: <54378CC0.2060602@redhat.com> Date: Fri, 10 Oct 2014 07:38:00 -0000 From: Phil Muldoon MIME-Version: 1.0 To: Doug Evans , Stan Shebs CC: gdb-patches Subject: Re: Deprecating (and deleting) user-facing APIs [was Re: Why do functions objfpy_new and pspy_new exist?] References: In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2014-10/txt/msg00232.txt.bz2 On 09/10/14 19:07, Doug Evans wrote: > (where the date is probably expressed in terms of number of releases from now). We want to give users time to migrate away from things that will eventually be deleted, and I can imagine the length of time being more than one release. Thus we need to publish the current state in a place where users can find it and track it. I don't have a strong opinion on where this documentation lives. Anyone have a strong opinion on where this should live? I can see an argument made for keeping it with the sources. As a strawman we could have a "Deprecated APIs" section in gdb.texinfo. I would also add an easy to find link to the currently generated form from the website. I'd also add appropriate entries to NEWS of course. Comments? I think it should live: 1) In the code comments. 2) In any user facing documentation, both the manual and any printed help 3) Maybe on the wiki too. I agree with the NEWS file. Also with the manual, if we have a deprecated API section, I think it should be bound to the section it refers to (IE Python has its own deprecated section). We can link all of these together in one master list or something. While we are here pondering these, I would also like to bring up deprecating versions of Python. It has become a difficult and time consuming chore at review time (and at release time) to ensure that we support as many Python versions as we do. Python 2.x and Python 3.x are moving ever further apart in an incompatible way. The amount of people working on the Python support, along with their other duties (I have been tied up with the GDB compile and inject support deeply over the last six months) really is insufficient. It will only get worse I think. The time I do have goes into checking reviews and any code I write works across the Python board. Time that could be spent elsewhere on newer features. So let me propose something. From GDB 8 on-wards, lets only support Python 3.x. If this is too early, maybe 8.1 or 8.2. Anyway, we message this consistently and continuously to the community. Document it in all the right high traffic places. What do folks think? Cheers, Phil PS, Sorry Doug, on reading back it looks like I might have hijacked or slightly segued your original topic! But all of this stuff is tied together.