emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: trunk r115926: In preparation for the move to git, sanitize out some


From: Juanma Barranquero
Subject: Re: trunk r115926: In preparation for the move to git, sanitize out some Bazaar-specific names.
Date: Thu, 9 Jan 2014 14:27:47 +0100

On Thu, Jan 9, 2014 at 2:13 PM, Eric S. Raymond <address@hidden> wrote:

> Wouldn't defining emacs-bzr-get-version as an obsolete function alias
> for emacs-repository-get-version solve the problem in a way
> satisfactory to both of us?

Sorry, no. It is not compatible. Code has been written that
understands the case that emacs-bzr-version isn't bound, or bound and
nil, or bound and meaningful (with structure). That code will have to
be changed if you insist in conflating it with your higher-level API
which IMO is not really a new layer (Emacs is not going to have to
deal with several underlying DVCS at once in its repository, as you
said yourself a few messages ago; DVCS-specific functions and
variables are not only not a bug, but a feature).

> It wouldn't reintroduce a layering bug into loadup.el, and it would give you
> your compatible API.

Even accepting that it is a layering bug (which I don't), there's no
problem in keeping it in loadup.el; that's why we have
make-obsolete(-variable). We don't need to clean up in a hurry every
possible clue of past mistakes; just fix the mistakes. And, as said,
what you offer is not compatible. emacs-repository-version is not
compatible with emacs-bzr-version; the structure was documented, it
never was a magical, opaque cookie.

    J



reply via email to

[Prev in Thread] Current Thread [Next in Thread]