From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: RFC: Adding BBDB to Emacs core Date: Tue, 24 Apr 2018 18:31:39 -0400 Message-ID: References: <87lgdpphmm.fsf@ericabrahamsen.net> <87sh7mjd7d.fsf@russet.org.uk> <87lgddgaga.fsf@russet.org.uk> <87bme8b7u9.fsf@russet.org.uk> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1524608991 2662 195.159.176.226 (24 Apr 2018 22:29:51 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 24 Apr 2018 22:29:51 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: emacs-devel@gnu.org To: phillip.lord@russet.org.uk (Phillip Lord) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Apr 25 00:29:46 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fB6RW-0000cd-I3 for ged-emacs-devel@m.gmane.org; Wed, 25 Apr 2018 00:29:46 +0200 Original-Received: from localhost ([::1]:32882 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fB6Td-0004of-EX for ged-emacs-devel@m.gmane.org; Tue, 24 Apr 2018 18:31:57 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44115) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fB6TR-0004nr-R5 for emacs-devel@gnu.org; Tue, 24 Apr 2018 18:31:46 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fB6TO-0006iD-Nk for emacs-devel@gnu.org; Tue, 24 Apr 2018 18:31:45 -0400 Original-Received: from pruche.dit.umontreal.ca ([132.204.246.22]:51033) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fB6TO-0006fC-HQ for emacs-devel@gnu.org; Tue, 24 Apr 2018 18:31:42 -0400 Original-Received: from pastel.home (lechon.iro.umontreal.ca [132.204.27.242]) by pruche.dit.umontreal.ca (8.14.7/8.14.1) with ESMTP id w3OMVd0N019671; Tue, 24 Apr 2018 18:31:40 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 9755467F70; Tue, 24 Apr 2018 18:31:39 -0400 (EDT) In-Reply-To: <87bme8b7u9.fsf@russet.org.uk> (Phillip Lord's message of "Tue, 24 Apr 2018 22:41:34 +0100") X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 2 Rules triggered EDT_SA_DN_PASS=0, RV6271=0 X-NAI-Spam-Version: 2.3.0.9418 : core <6271> : inlines <6586> : streams <1784994> : uri <2631117> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 132.204.246.22 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:224843 Archived-At: > As a package author, I have two choices here: either I move to Emacs-27 > and ditch Emacs-26 support. Or I have to put runtime conditional logic > which supports both. That's right. > I think package authors should have the choice of freezing the > Emacs-26 version of their package when Emacs-27 comes out. There's a case to be made for allowing ELPA archives to exports several versions of a package at the same time, so older Emacsen can still install the old version of a package without having to download the old version by hand. But I'm not moved by your scenario: adding runtime conditional logic has been standard procedure "for ever" and comes with all kinds of advantages, such as the ability for older Emacsen to benefit from other improvements in the newer versions of your package, or an easier way to install&use the package with several different versions of Emacs at the same time, ... > This situation would get worse if we have an "unstable" version of > ELPA. I don't see why: "unstable" is just a preview of what will be "stable" a few weeks/months later and packages usually preserve compatibility at least with Emacsen that are a few years old. > I bet that there is some package already that depends on Emacs-27 > at the bleeding edge. I strongly doubt it. Stefan