From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.devel Subject: RE: Delete variables obsolete since Emacs 23 Date: Wed, 19 Aug 2020 06:26:04 -0700 (PDT) Message-ID: <14b29241-1f00-441e-bc70-588d0d6b1ad4@default> References: <83r1s4ftc7.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="31915"; mail-complaints-to="usenet@ciao.gmane.io" To: emacs-devel@gnu.org, Gregory Heytings Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Aug 19 15:28:59 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1k8O9D-00089Y-9h for ged-emacs-devel@m.gmane-mx.org; Wed, 19 Aug 2020 15:28:59 +0200 Original-Received: from localhost ([::1]:41540 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1k8O9C-0002PB-BT for ged-emacs-devel@m.gmane-mx.org; Wed, 19 Aug 2020 09:28:58 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:56974) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1k8O8a-0001wm-2o for emacs-devel@gnu.org; Wed, 19 Aug 2020 09:28:20 -0400 Original-Received: from userp2130.oracle.com ([156.151.31.86]:40840) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1k8O8X-0000Mu-Vv for emacs-devel@gnu.org; Wed, 19 Aug 2020 09:28:19 -0400 Original-Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 07JDSG6S045987; Wed, 19 Aug 2020 13:28:16 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2020-01-29; bh=UDT06VR57Awj4KdZDrcv4WZBMfkOfwydzh301Iprdsk=; b=uSH2tmemdnXBGqK8Q2yExbhQtKc44OGzu7cyhn69Pi9HfXF5+N6uYSiqge5DTuGcM8lL D1Sn5JVIuY7s61jD5jDe+ptItp8K9xs1f6j0bYR/DTD0VN1FlpNcynwasPrjblOunMyn L7ZW/9bxygR0AkaWXhF4x2J7OnaagvZQhciRnPFDdSIj068KSVZVp6bO708wL6EW3h7q CggfBZ0SEUaZ5z/JmHPJ4t3lTa6YBYiN/ZoEhZ9+1dcA5AwpWJiymQZ+swgwcy251ejB gsNi0UX74i9FEsyNbZttlELVrvYY/v2UXhm6PdSh3XK3P1bi+SokRNCUMjxvBDa1vgx4 PQ== Original-Received: from userp3030.oracle.com (userp3030.oracle.com [156.151.31.80]) by userp2130.oracle.com with ESMTP id 32x74ranks-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 19 Aug 2020 13:28:16 +0000 Original-Received: from pps.filterd (userp3030.oracle.com [127.0.0.1]) by userp3030.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 07JDN0wS149201; Wed, 19 Aug 2020 13:26:16 GMT Original-Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userp3030.oracle.com with ESMTP id 32xsmypq0q-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 19 Aug 2020 13:26:15 +0000 Original-Received: from abhmp0003.oracle.com (abhmp0003.oracle.com [141.146.116.9]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id 07JDQEhU012170; Wed, 19 Aug 2020 13:26:15 GMT In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.5017.0 (x86)] X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9717 signatures=668679 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 malwarescore=0 spamscore=0 bulkscore=0 mlxlogscore=999 phishscore=0 mlxscore=0 suspectscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2008190118 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9717 signatures=668679 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 impostorscore=0 mlxlogscore=999 priorityscore=1501 phishscore=0 spamscore=0 mlxscore=0 adultscore=0 suspectscore=0 lowpriorityscore=0 bulkscore=0 malwarescore=0 clxscore=1015 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2008190118 Received-SPF: pass client-ip=156.151.31.86; envelope-from=drew.adams@oracle.com; helo=userp2130.oracle.com X-detected-operating-system: by eggs.gnu.org: First seen = 2020/08/19 09:28:16 X-ACL-Warn: Detected OS = Linux 3.1-3.10 [fuzzy] X-Spam_score_int: -63 X-Spam_score: -6.4 X-Spam_bar: ------ X-Spam_report: (-6.4 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-1, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:254002 Archived-At: > >> The phrase "may be removed" seems a bit vague. Would "will be removed= " > >> or "will probably be removed" be more accurate? > > > > No, it won't. Primarily because we don't really know whether we will > > remove it, let alone when. It depends on too many factors that we > > cannot predict. > > >=20 > In that case, would a two-step process not be better? First declaring th= e > function "obsolete", and when it is known that it will be removed declare > it "pending-removal" with a target major version. In my experience, organizations typically avoid a lot of commitments to future changes. Instead, it's about _no longer_ committing to something that's currently committed to. It's about removal of commitments, not imposition of new commitments. (Sometimes there's informal/unofficial mention to some users that it's likely XYZ will be removed at a specific point. But even that is generally avoided.) Typically there are two possible stages: 1. Deprecation (sometimes calling the thing "obsolete"). The thing _remains supported_. There's no longer a _commitment_ to active development - that's all. Users are told that the thing _might_ be desupported at some time in the future. Because of the removal of a _commitment_ to actively develop AND the removal of a _commitment_ that the thing will remain forever, users are advised to start moving away from using the thing. 2. Desupport. This is _optional_. A deprecated thing need never be desupported. And typically there is some (sometimes announced, sometimes not) minimal time period or number of intermediate releases, needed between deprecation and desupport. Something that's desupported gets no support. Trying to use it typically results in a no-op or raising an error. ___ That's my experience. YMMV. And of course nothing requires GNU Emacs to follow any particular outside convention or typical behavior.