From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21778 invoked by alias); 10 Oct 2014 16:35:56 -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 21764 invoked by uid 89); 10 Oct 2014 16:35:56 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-vc0-f181.google.com Received: from mail-vc0-f181.google.com (HELO mail-vc0-f181.google.com) (209.85.220.181) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Fri, 10 Oct 2014 16:35:53 +0000 Received: by mail-vc0-f181.google.com with SMTP id le20so2968802vcb.12 for ; Fri, 10 Oct 2014 09:35:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=6e88mpzBHgvGy5dLMQlnCyRqZQ9VMRZXucumaf97pFs=; b=SKNeEm1+2iHiLLEyGU4qKyGEtGc8VPhEfBUn4MDiLIpgXMbc3P0vdWfLV95bIT+nWk 3ZbUFt6gyqVCxadJipO9GvI/5+7YTQqIHtec2dpWC81L+8LlkTaIM4WxRKFG+vMYV8Xz Fgd4BgAmulubmR3CizTdBGZ4vQwqlmx9EDanMv59u7DZaxCGaYvlXHpk7eLw447LXcT0 kvJASq+jVDRNkSaRgEmg8X3Ev4oDwa1MvKxqKLZGaLb7+5GUINEyMVETuvQk+CiJXXN0 YMMl4xaIyuI1fbrULH0cyqXlKpuRLdUx4X6wlSWmSnh5IMPC+/4EAILfFNaTn9CdnXnz Z39g== X-Gm-Message-State: ALoCoQkdGU39MziklpBZd4D8bkMm2E+cqiEt+Q4GaoOUHryvJrLuUBStGXf1PyavaYzdjKkOk7jF MIME-Version: 1.0 X-Received: by 10.220.169.75 with SMTP id x11mr3851928vcy.36.1412958951265; Fri, 10 Oct 2014 09:35:51 -0700 (PDT) Received: by 10.52.181.65 with HTTP; Fri, 10 Oct 2014 09:35:51 -0700 (PDT) In-Reply-To: <54378CC0.2060602@redhat.com> References: <54378CC0.2060602@redhat.com> Date: Fri, 10 Oct 2014 16:35:00 -0000 Message-ID: Subject: Re: Deprecating (and deleting) user-facing APIs [was Re: Why do functions objfpy_new and pspy_new exist?] From: Doug Evans To: Phil Muldoon Cc: Stan Shebs , gdb-patches Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2014-10/txt/msg00250.txt.bz2 On Fri, Oct 10, 2014 at 12:37 AM, Phil Muldoon wrote: > On 09/10/14 19:07, Doug Evans wrote: >> (where the date is probably expressed in terms of number of releases fro= m now). We want to give users time to migrate away from things that will ev= entually be deleted, and I can imagine the length of time being more than o= ne release. Thus we need to publish the current state in a place where user= s can find it and track it. I don't have a strong opinion on where this doc= umentation 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 al= so 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. It's important that this stuff stay up to date and in sync. I'm ok with a link on the wiki to the generated html form of the docs, but I'm uncomfortable with having the data appear in multiple places. > 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. Yeah. I think we'll need 2.x for awhile, but it's certainly desirable to require 2.7, and deprecate/delete support for everything prior. > > 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. No worries.