From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Juanma Barranquero Newsgroups: gmane.emacs.devel Subject: Re: trunk r115926: In preparation for the move to git, sanitize out some Bazaar-specific names. Date: Thu, 9 Jan 2014 16:21:15 +0100 Message-ID: References: <20140109052705.GA3424@thyrsus.com> <20140109123702.GB5361@thyrsus.com> <20140109131337.GA6053@thyrsus.com> <20140109134716.GA6290@thyrsus.com> <20140109142956.GA6731@thyrsus.com> <20140109150851.GA7194@thyrsus.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: ger.gmane.org 1389280946 13913 80.91.229.3 (9 Jan 2014 15:22:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 9 Jan 2014 15:22:26 +0000 (UTC) Cc: Bastien , Emacs developers To: Eric Raymond Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jan 09 16:22:33 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1W1HRI-0000Hu-QY for ged-emacs-devel@m.gmane.org; Thu, 09 Jan 2014 16:22:32 +0100 Original-Received: from localhost ([::1]:52575 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W1HRI-00041X-Dp for ged-emacs-devel@m.gmane.org; Thu, 09 Jan 2014 10:22:32 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60520) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W1HQp-0003Sp-3c for emacs-devel@gnu.org; Thu, 09 Jan 2014 10:22:04 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W1HQn-0007k4-VY for emacs-devel@gnu.org; Thu, 09 Jan 2014 10:22:03 -0500 Original-Received: from mail-ee0-x230.google.com ([2a00:1450:4013:c00::230]:61086) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W1HQl-0007jT-SC; Thu, 09 Jan 2014 10:22:00 -0500 Original-Received: by mail-ee0-f48.google.com with SMTP id e49so1390461eek.7 for ; Thu, 09 Jan 2014 07:21:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=iE+H4KfJSAunbGMOhDTBXlDj1QYA4id+F/6VJxexnQc=; b=q3eC7I07UdGpqwHKrawzA9UEX5Zj7qgys2Z0s+AMw02GaZHfJXR8oyusG1ZK8/A+l3 APSBMNTPbEw+935OUcL0HrYOFIQJrlzT85l7Xr72qzch+7UWka4bYG8czXezdebsGQSj bDGgBmxO3Sp4hVq3bc8WRMj/j6XvEDRzru/nSb7797CAThw5v4Fj0Qeu9hx99QzDELoC 0hrAC1gtrhC7MBg/jVbolj7AnQo3xXF073gz8+heVvpi0MXmP5DtABAn6wtirJqBL8Qh iwkLK1PK8slBGT15CChz0WNfFCvQYogFrUOE4vgofy/t++cHMXuw4WChtoPlS3u7/w1U 0d7g== X-Received: by 10.14.108.6 with SMTP id p6mr3834032eeg.31.1389280917071; Thu, 09 Jan 2014 07:21:57 -0800 (PST) Original-Received: by 10.14.209.69 with HTTP; Thu, 9 Jan 2014 07:21:15 -0800 (PST) In-Reply-To: <20140109150851.GA7194@thyrsus.com> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:4013:c00::230 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:167925 Archived-At: On Thu, Jan 9, 2014 at 4:08 PM, Eric S. Raymond wrote: > That's before putting the function alias in place, right? No, I aliased emacs-bzr-get-version to emacs-repository-get-version before evalling that code. The error is because (read emacs-repository-version) will not be guaranteed to return an integer. > That is incorrect. emacs-bzr-get-version will return *exactly the name thing* > as it did before the change, *under all circumstances*. Not true. - Before: => nnnn some-bzr-revid - Now: => nnnn some-bzr-revid (because of the alias) - In the future, *without* the alias => nil - In the future, *with* your alias => some-git-revid > That's right. The old API was misdesigned; it leaked information that > it should not. Misdesigned or not (and it was not: it gave me useful information), it's what it was, what still would be if you hadn't broken it. You want to design a better API? By all means, do it. Just leave the old one as obsolete. > Since that can be fixed in a compatible way, it should be. "Fixing it in a compatible way" is what I try to do, and you refuse: - Introduce your newfangled API - Leave the old one as obsolete. You're "breaking it in an incompatible way", which is quite different. J