Re: trunk r115926: In preparation for the move to git, sanitize out some Bazaar-specific names.

[Juanma Barranquero <lekktu@gmail.com>]

On Thu, Jan 9, 2014 at 6:27 AM, Eric S. Raymond <esr@thyrsus.com> wrote:

> When we change
> over to git, there won't be a local revision number because there is
> no such entity in the git universe.  This can't be fixed by anything
> in the way our LISP is named or factored.

True.

> You're making a good case for removing the obsolete alias.

No. I'm making a case for keeping both variables (and functions)
different. You've rushed a bit with the change, and currently, if you
remove the alias, you'll break my code**. The logical things would be
to keep emacs-bzr(-get)-version as they were, because we *are* still
using Bazaar, and when we switch, or just a bit before, you introduce
your new API (with "repository" or "git" names, to your liking) and
make the old ones obsolete, but *not* obsolete aliases.

**[It's broken right now, in fact; I also use emacs-bzr-get-version
from my .emacs]

> It might, if we were going to use two VCSes in parallel. That's not
> the case.  Where the rubber meets the road is: What should emacs-bug call to
> get a build version to report? There can be only one...

Yes. Currently, it's Bazaar that we are using. After the switch, it
should call your function. Having the two (but one pair as obsolete
non-aliases) does not depend of using two VCSes in parallel, depends
that the fact that you're changing an already published API. So you
have to make it obsolete, and it cannot be an alias of the new one
because both aren't compatible.

> The implementation, no. But the behavior "return a unique magic cookie
> that identifies the build" is DVCS-independent.  You're feeling pain
> because you want the magic cookie to have substructure, and *that*
> can't be guaranteed across VCSes.

Eric, the behavior of the old emacs-bzr(-get)-version was not to
"return a unique magic cookie that identifies the build". I am not
using the revno because I wanted to do weird things with the cookie.
It was *documented* as having structure and I used that fact; it's
your commits which have changed it, so you're effectively changing
that interface. Which it's perhaps the right thing to do (or not,
depending of what the cookie has I will still extract information from
it, so documenting it would be nice), but you shouldn't rewrite the
past.

So, to summarize, I think the right thing to do is:

1.- Restore emacs-bzr(-get)-version, with docstring and all.
2.- (Keep, if you want, your new and currently useless
emacs-revision(-get)-version API)
3.- Just after the switch, make obsolete the old pair with

(make-obsolete 'emacs-bzr-get-version 'emacs-repository-get-version "24.4")
(make-obsolete-variable 'emacs-bzr-version 'emacs-repository-version "24.4")

    J