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

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

[Glenn Morris]

"Eric S. Raymond" wrote:

> -** If your Emacs was built from a bzr checkout, the new variable
> -`emacs-bzr-version' contains information about the bzr revision used.
> +** If your Emacs was built from a repository checkout, the new variable
> +`emacs-repository-version' contains information about the bzr revision used.

This entry was in the NEWS section corresponding to the already-released
24.3, so should not have been changed.

Perhaps there should be an obsolete variable alias emacs-bzr-version,
since it existed in the previous release and now does not.

(Actually, I don't think it should have been changed at all during a
feature freeze.)

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

[Eric S. Raymond]

Glenn Morris <rgm@gnu.org>:
> > -** If your Emacs was built from a bzr checkout, the new variable
> > -`emacs-bzr-version' contains information about the bzr revision used.
> > +** If your Emacs was built from a repository checkout, the new variable
> > +`emacs-repository-version' contains information about the bzr revision used.
> 
> This entry was in the NEWS section corresponding to the already-released
> 24.3, so should not have been changed.

Oops.  I thought it was in the 24.4 section; I'll revert that and make sure
the name change is properly noted in the 24.4 news.
 
> Perhaps there should be an obsolete variable alias emacs-bzr-version,
> since it existed in the previous release and now does not.

I think it is *highly* doubtful anyone ever used it...
 
> (Actually, I don't think it should have been changed at all during a
> feature freeze.)

Perhaps not.  But I did get a request that the stuff around (what is now)
emacs-repository-version be fixed immediately so that at no point would
any bug report lack a repository revision stamp.

My next intended change is to modify a bit of Lisp so that this variable
is set properly whether the repo type is Bazaar or Git.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

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

[Juanma Barranquero]

On Thu, Jan 9, 2014 at 12:34 AM, Eric S. Raymond <esr@thyrsus.com> wrote:
> Glenn Morris <rgm@gnu.org>:
>> Perhaps there should be an obsolete variable alias emacs-bzr-version,
>> since it existed in the previous release and now does not.
>
> I think it is *highly* doubtful anyone ever used it...

I use emacs-bzr-version in my .emacs. Please add an obsolete alias if
you really have to rename it.

Thanks,

      J

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

[Eric S. Raymond]

Juanma Barranquero <lekktu@gmail.com>:
> I use emacs-bzr-version in my .emacs. Please add an obsolete alias if
> you really have to rename it.

That name was hardly going to serve well once we moved to Git, was it?

I don't know how to create an obsolete alias.  Can you point me at
an example to emulate?
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

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

[Daniel Colascione]

On 01/08/2014 04:04 PM, Eric S. Raymond wrote:
> Juanma Barranquero <lekktu@gmail.com>:
>> I use emacs-bzr-version in my .emacs. Please add an obsolete alias if
>> you really have to rename it.
>
> That name was hardly going to serve well once we moved to Git, was it?
>
> I don't know how to create an obsolete alias.  Can you point me at
> an example to emulate?

Look for define-obsolete-function-alias.

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

[Bastien]

"Eric S. Raymond" <esr@thyrsus.com> writes:

> I don't know how to create an obsolete alias.  Can you point me at
> an example to emulate?

C-h f define-obsolete-function-alias RET
C-h f define-obsolete-variable-alias RET

-- 
 Bastien

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

[Juanma Barranquero]

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

> That name was hardly going to serve well once we moved to Git, was it?

I think it's safe to assume most of us didn't expect a switch to Git
for many years to come.

Anyway, it's irrelevant whether it would serve me well at some point
in the future; when I used it, that's what the variable was named. :-)

> I don't know how to create an obsolete alias.  Can you point me at
> an example to emulate?

(define-obsolete-variable-alias 'emacs-bzr-version
'emacs-repository-version "24.4")

HTH,

   J

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

[Eric S. Raymond]

Daniel Colascione <dancol@dancol.org>:
> On 01/08/2014 04:04 PM, Eric S. Raymond wrote:
> >Juanma Barranquero <lekktu@gmail.com>:
> >>I use emacs-bzr-version in my .emacs. Please add an obsolete alias if
> >>you really have to rename it.
> >
> >That name was hardly going to serve well once we moved to Git, was it?
> >
> >I don't know how to create an obsolete alias.  Can you point me at
> >an example to emulate?
> 
> Look for define-obsolete-function-alias.

Hm.  Is there a define-obsolete-variable-alias?
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

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

[Daniel Colascione]

On 01/08/2014 04:12 PM, Eric S. Raymond wrote:
> Daniel Colascione <dancol@dancol.org>:
>> On 01/08/2014 04:04 PM, Eric S. Raymond wrote:
>>> Juanma Barranquero <lekktu@gmail.com>:
>>>> I use emacs-bzr-version in my .emacs. Please add an obsolete alias if
>>>> you really have to rename it.
>>>
>>> That name was hardly going to serve well once we moved to Git, was it?
>>>
>>> I don't know how to create an obsolete alias.  Can you point me at
>>> an example to emulate?
>>
>> Look for define-obsolete-function-alias.
>
> Hm.  Is there a define-obsolete-variable-alias?

Yep.

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

[Eric S. Raymond]

Bastien <bzg@gnu.org>:
> "Eric S. Raymond" <esr@thyrsus.com> writes:
> 
> > I don't know how to create an obsolete alias.  Can you point me at
> > an example to emulate?
> 
> C-h f define-obsolete-function-alias RET
> C-h f define-obsolete-variable-alias RET

The argument WHEN is not described in the function docstring. Is it supposed
to be the last version in which the old name was valid, or the first version
in which the new name was?
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

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

[Glenn Morris]

"Eric S. Raymond" wrote:

> But I did get a request that the stuff around (what is now)
> emacs-repository-version be fixed immediately so that at no point
> would any bug report lack a repository revision stamp.

I believe the request was that it keep working across the switch,
whenever that happens, not that it get changed Right Now in trunk.

After the feature freeze ends (which I guess will be no more than a few
weeks from now), the 24.4 release will be split off to the emacs-24
branch, and the trunk will be available for development again. It will
be some time (I guess no less than a few months) after this that 24.4 is
released; and nobody said this transition had to happen immediately
after that anyway.

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

[Juanma Barranquero]

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

> The argument WHEN is not described in the function docstring. Is it supposed
> to be the last version in which the old name was valid, or the first version
> in which the new name was?

Second option. It says in which version the new name is introduced and
the old name turns into an obsolete alias.

     J

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

[Eric S. Raymond]

Juanma Barranquero <lekktu@gmail.com>:
> On Thu, Jan 9, 2014 at 1:27 AM, Eric S. Raymond <esr@thyrsus.com> wrote:
> 
> > The argument WHEN is not described in the function docstring. Is it supposed
> > to be the last version in which the old name was valid, or the first version
> > in which the new name was?
> 
> Second option. It says in which version the new name is introduced and
> the old name turns into an obsolete alias.

Thanks.  I'll include the obsolete-alias setup with some docstring fixes
that version.el meeded anyway.

The theme of all my recent commits is fixing places in the tree where code
or documentation knew the VCS in use is Bazaar but didn't actually need 
to know that. In most cases simply referring to 'the repository' is 
sufficient, and in fact improves the documentation.

The goal, of course, is to get to where plugging in git is a very small
and well-isolated change.  But these cleanups would be good in themselves for
their information-hiding effects even if no change were planned.

The renaming of that variable is the most intrusive change I'll have
to make to get this part of the job done.  Most of the others are
documentation.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

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

[Juanma Barranquero]

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

> I'll include the obsolete-alias setup with some docstring fixes
> that version.el meeded anyway.

Thanks.

> But these cleanups would be good in themselves for
> their information-hiding effects even if no change were planned.

I agree, though I also agree with Glenn in that it wasn't really
necessary right now, as Stefan has suggested, IIUC, that the switch
won't happen until the freeze is over. But no big deal anyway.

   J

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

[Juanma Barranquero]

On second thought, I'm not so sure that renaming emacs-bzr-version and
emacs-bzr-get-version is a good idea (though I agree with your other
changes, to remove Bazaar-specific references in docs, etc.)

The reason is that emacs-repository-version and
emacs-repository-get-version won't be true replacements for the
current variable and function. They won't contain or return data in
the same format, and I won't be able, for example, to just use
emacs-repository-version in the same way I'm using emacs-bzr-version
right now. It's not possible, because I'm using the fact that their
value started with a numerical revno (I'm doing arithmetic with that
value), which does not make sense in Git. I will be forced to change
my code, so just making emacs-bzr-version into an obsolete alias of
emacs-repository-version is misleading.

IMO it would make more sense to define new emacs-git-version and
emacs-git-get-version instances and let user code sort which one needs
to use. These function and variable are never going to be really
repository- or DVCS-independent anyway. And it's not like we're likely
to switch DVCS again in a few years...

    J

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

[Stephen J. Turnbull]

Juanma Barranquero writes:

 > Anyway, it's irrelevant whether it would serve me well at some point
 > in the future; when I used it, that's what the variable was
 > named. :-)

More important, Emacsen built from the bzr repo are not going to go
away.  People are going to be making the transition over a period of
*years*, not months.  Probably only developers are really interested
in this variable, but you just never know what 3rd parties are going
to put in their packages or .emacs.

Continuity is a good thing.

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

[Eric S. Raymond]

Juanma Barranquero <lekktu@gmail.com>:
> On second thought, I'm not so sure that renaming emacs-bzr-version and
> emacs-bzr-get-version is a good idea
>
> The reason is that emacs-repository-version and
> emacs-repository-get-version won't be true replacements for the
> current variable and function. They won't contain or return data in
> the same format, and I won't be able, for example, to just use
> emacs-repository-version in the same way I'm using emacs-bzr-version
> right now.

That's true, but it has nothing to do with how the function and 
vaeriable are named and cannot be fixed by changing the name back
or twinning the function.

If you look at emacs-repository-version, it now returns exactly what
you're used to with the bzr local revision number up front.  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.

> It's not possible, because I'm using the fact that their
> value started with a numerical revno (I'm doing arithmetic with that
> value), which does not make sense in Git. I will be forced to change
> my code, so just making emacs-bzr-version into an obsolete alias of
> emacs-repository-version is misleading.

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

> IMO it would make more sense to define new emacs-git-version and
> emacs-git-get-version instances and let user code sort which one needs
> to use.

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...

>  These function and variable are never going to be really
> repository- or DVCS-independent anyway.

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.  But reverting my renames wouldn't
solve that problem either.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

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

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Date: Wed, 08 Jan 2014 19:34:32 -0500
> Cc: emacs-devel@gnu.org
> 
> "Eric S. Raymond" wrote:
> 
> > But I did get a request that the stuff around (what is now)
> > emacs-repository-version be fixed immediately so that at no point
> > would any bug report lack a repository revision stamp.
> 
> I believe the request was that it keep working across the switch,
> whenever that happens, not that it get changed Right Now in trunk.

Yes, that's what I meant.  Sorry if it was unclear.

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

[Juanma Barranquero]

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

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

[Rüdiger Sonderfeld]

On Thursday 09 January 2014 00:27:05 Eric S. Raymond wrote:
> 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.  But reverting my renames wouldn't
> solve that problem either.

I think the problem is that `emacs-bzr-version' specified a certain format.  
It will probably be worse to change it to a different format than simply 
setting it to nil and marking it obsolete (and quickly removing it).  Instead 
of turning it into an alias.

Regards,
Rüdiger

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

[Juanma Barranquero]

On Thu, Jan 9, 2014 at 1:00 PM, Rüdiger Sonderfeld
<ruediger@c-plusplus.de> wrote:

> It will probably be worse to change it to a different format than simply
> setting it to nil and marking it obsolete

Yes. Nil, or, not to break code, a string with the last Bazaar
revision before the switch.

> (and quickly removing it).

Why? We've had variables marked obsolete for years (10+). There's no
need to remove it "quickly".

     J

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

[Rüdiger Sonderfeld]

On Thursday 09 January 2014 13:12:15 Juanma Barranquero wrote:
> On Thu, Jan 9, 2014 at 1:00 PM, Rüdiger Sonderfeld
> 
> <ruediger@c-plusplus.de> wrote:
> > It will probably be worse to change it to a different format than simply
> > setting it to nil and marking it obsolete
> 
> Yes. Nil, or, not to break code, a string with the last Bazaar
> revision before the switch.

nil is a specified value: "Value is nil if Emacs was not built from a bzr 
checkout, or if we could not determine the revision."

Fixing it to the last bzr revision seems like a bad idea.

Regards,
Rüdiger

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

[Juanma Barranquero]

On Thu, Jan 9, 2014 at 1:20 PM, Rüdiger Sonderfeld
<ruediger@c-plusplus.de> wrote:

> nil is a specified value: "Value is nil if Emacs was not built from a bzr
> checkout, or if we could not determine the revision."

Yes, you're right.

Anyway, it's not really important, as long as the variable and
function are kept and marked as obsolete (once they are obsolete,
which they currently aren't).

     J

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

[Eric S. Raymond]

Juanma Barranquero <lekktu@gmail.com>:
> 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")

I must be missing something.  I don't see how this would solve any problem
at all.

I don't understand why simply looking at emacs-bzr-version isn't working
for you, given that it's now aliased.

What would (emacs-bug) look at under this plan?  If your answer is 
emacs-bzr-version, I strongly object.  The fact that the VCS name
was exposed at that level was a *bug*, a layering violation (and I would
say the same thing if the name had been emacs-git-version). Nothing
in Lisp outside version.el has need to know that and therefore 
should not know it.

You're going to have a flag day either way when the VCS changes; I
don't get why pushing it into the future by deferring the rename would
help you.

I don't see any win at all in this reversion. And because doing it would
reintroduce a layering violation, I'm going to need a lot of convincing.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

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

[Juanma Barranquero]

On Thu, Jan 9, 2014 at 1:37 PM, Eric S. Raymond <esr@thyrsus.com> wrote:

> I must be missing something.  I don't see how this would solve any problem
> at all.

It's no different of any other change that obsoletes a variable. Old
code uses it, even if there's newer code with improved features.

> I don't understand why simply looking at emacs-bzr-version isn't working
> for you, given that it's now aliased.

It is working (at least, the part that does not call
emacs-bzr-get-version, which does not exist anymore). I'm saying that
my previous suggestion of defining an obsolete alias is wrong, because
the old and the new variables are NOT compatible.

> What would (emacs-bug) look at under this plan?  If your answer is
> emacs-bzr-version, I strongly object.

Currently? emacs-bzr-version. After the switch? Whatever you want.

>  The fact that the VCS name
> was exposed at that level was a *bug*, a layering violation (and I would
> say the same thing if the name had been emacs-git-version). Nothing
> in Lisp outside version.el has need to know that and therefore
> should not know it.

That it is a layering violation is a matter of opinion. That is was
documented as having a specific structure is a fact, and that at least
one person in the universe (though perhaps more, as it has been
available since 24.3, almost a year ago) is using it, is another fact.
These aren't up for discussion. I understand that you feel strongly
about how that API should be, and I'm not opposing your changes in the
future. But I don't accept that you have the right to rewrite the past
and just *remove* a published API because you think it is wrong
(*even* if you're right) when we have a perfectly clear mechanism to
deal with such situations, named obsolescence.

> I don't see any win at all in this reversion. And because doing it would
> reintroduce a layering violation, I'm going to need a lot of convincing.

Why should I have to convince you that you shouldn't remove published
APIs? I don't want to turn this into a silly commit battle, but if you
don't fix it in a compatible way, I will. I'm only asking that your
changes for the future (need I to remind you that we're still using
Bazaar?) do not break anything that does not *need* to be broken.

     J

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

[Eric S. Raymond]

Juanma Barranquero <lekktu@gmail.com>:
> > I don't see any win at all in this reversion. And because doing it would
> > reintroduce a layering violation, I'm going to need a lot of convincing.
> 
> Why should I have to convince you that you shouldn't remove published
> APIs? I don't want to turn this into a silly commit battle, but if you
> don't fix it in a compatible way, I will. I'm only asking that your
> changes for the future (need I to remind you that we're still using
> Bazaar?) do not break anything that does not *need* to be broken.

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?

It wouldn't reintroduce a layering bug into loadup.el, and it would give you
your compatible API. 
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

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

[Juanma Barranquero]

On Thu, Jan 9, 2014 at 2:13 PM, Eric S. Raymond <esr@thyrsus.com> 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

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

[Eric S. Raymond]

Juanma Barranquero <lekktu@gmail.com>:
> On Thu, Jan 9, 2014 at 2:13 PM, Eric S. Raymond <esr@thyrsus.com> 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

The more you talk about this, the less you're making any sense to me.

All this about the return value having structure is a red herring. You
still *get* that structure by looking at emacs-bzr-version.  I have
not changed that and will not; only the VCS transition will do that.

Similarly, the unbound and bound-but-nil cases will still work; that's
the point of declaring an alias, isn't it?

With both the variable and function alias in place, I don't understand
what code would need to be changed.  Show me.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

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

[Juanma Barranquero]

On Thu, Jan 9, 2014 at 2:47 PM, Eric S. Raymond <esr@thyrsus.com> wrote:

> The more you talk about this, the less you're making any sense to me.

Same here.

> All this about the return value having structure is a red herring. You
> still *get* that structure by looking at emacs-bzr-version.  I have
> not changed that and will not; only the VCS transition will do that.

Yes. And after the transition, code that depends on
emacs-release-version and emacs-release-get-version will get a string
with a different structure. With your current aliases, they will
continue existing, and they will return something different. That is
an incompatible change.

> With both the variable and function alias in place, I don't understand
> what code would need to be changed.

(and (bound-and-true-p emacs-bzr-version)
     (- (read (emacs-bzr-get-version))
        (read emacs-bzr-version)))

This fails right now because you didn't introduce an alias for
emacs-bzr-get-version. But, once that is fixed, it will still fail
after the switch because emacs-bzr(-get)-version won't return a string
containing a revno.

So the only compatible fix is to keep these, not as aliases, but as obsolete.

    J

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

[Eric S. Raymond]

Juanma Barranquero <lekktu@gmail.com>:
> So the only compatible fix is to keep these, not as aliases, but as obsolete.

By your own analysis, there is *no* compatible fix.  Whatever the function
and variable are called, stuff is going to break because the revision-ID
format is different.

Now explain to me how reverting the rename would make this

(and (bound-and-true-p emacs-bzr-version)
      (- (read (emacs-bzr-get-version))
         (read emacs-bzr-version)))

work any differently than with both aliases in place. (I agree that
not having the function alias in place was an error on my part.)
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

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

[Juanma Barranquero]

On Thu, Jan 9, 2014 at 3:29 PM, Eric S. Raymond <esr@thyrsus.com> wrote:

> By your own analysis, there is *no* compatible fix.  Whatever the function
> and variable are called, stuff is going to break because the revision-ID
> format is different.

It won't be able to extract the required information, because it will
not exist anymore. But, as that code is checking for nil, it won't
break. Your change will make it break:

(setq emacs-repository-version "fce2a09142ddccc242931edd16712c2c24e10e8e")

Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p
fce2a09142ddccc242931edd16712c2c24e10e8e)
  -(115933 fce2a09142ddccc242931edd16712c2c24e10e8e)
  (and (and (boundp (quote emacs-bzr-version)) emacs-bzr-version) (-
(read (emacs-bzr-get-version)) (read emacs-bzr-version)))
  eval((and (and (boundp (quote emacs-bzr-version)) emacs-bzr-version)
(- (read (emacs-bzr-get-version)) (read emacs-bzr-version))) nil)
  eval-last-sexp-1(nil)
  eval-last-sexp(nil)
  call-interactively(eval-last-sexp nil nil)
  command-execute(eval-last-sexp)

> work any differently than with both aliases in place.

Switching to Git with remove some functionality (specifically, being
easily able to check how many commits there are between the compiled
Emacs and the repository head). That cannot be helped, sort of looking
for alternatives. I'm not complaining about lack of functionality, but
code breaking.

But anyway, that's not even the issue. The issue is that we had an
interface which said that it would return a string with some format,
or nil. You want to keep that interface, but make it return something
different. That's incompatible *and* unnecessary. And you seem to
insist just because you don't like the idea of the old APIs being
around in loadup.el?

    J

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

[Eric S. Raymond]

Juanma Barranquero <lekktu@gmail.com>:
> On Thu, Jan 9, 2014 at 3:29 PM, Eric S. Raymond <esr@thyrsus.com> wrote:
> 
> > By your own analysis, there is *no* compatible fix.  Whatever the function
> > and variable are called, stuff is going to break because the revision-ID
> > format is different.
> 
> It won't be able to extract the required information, because it will
> not exist anymore. But, as that code is checking for nil, it won't
> break. Your change will make it break:
> 
> (setq emacs-repository-version "fce2a09142ddccc242931edd16712c2c24e10e8e")
> 
> Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p
> fce2a09142ddccc242931edd16712c2c24e10e8e)
>   -(115933 fce2a09142ddccc242931edd16712c2c24e10e8e)
>   (and (and (boundp (quote emacs-bzr-version)) emacs-bzr-version) (-
> (read (emacs-bzr-get-version)) (read emacs-bzr-version)))
>   eval((and (and (boundp (quote emacs-bzr-version)) emacs-bzr-version)
> (- (read (emacs-bzr-get-version)) (read emacs-bzr-version))) nil)
>   eval-last-sexp-1(nil)
>   eval-last-sexp(nil)
>   call-interactively(eval-last-sexp nil nil)
>   command-execute(eval-last-sexp)

That's before putting the function alias in place, right?  I'm going to push 
a change to fix that. The only reason I haven't already is that I have
another change waiting 

> But anyway, that's not even the issue. The issue is that we had an
> interface which said that it would return a string with some format,
> or nil.

That is correct.

> You want to keep that interface, but make it return something
> different. That's incompatible *and* unnecessary.

That is incorrect.  emacs-bzr-get-version will return *exactly the name thing*
as it did before the change, *under all circumstances*.  That's the point
of the alias. Are you telling me the alias geature doesn't work?  If so,
we have larger problems...

>                                            And you seem to
> insist just because you don't like the idea of the old APIs being
> around in loadup.el?

That's right.  The old API was misdesigned; it leaked information that
it should not. Since that can be fixed in a compatible way, it should be.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

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

[Juanma Barranquero]

On Thu, Jan 9, 2014 at 4:08 PM, Eric S. Raymond <esr@thyrsus.com> 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

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

[chad]

It’s probably dumb of me to jump in here, but…

If you make an obsolete ALIAS, you’re telling people that the same functionality exists under a new name. That is not what you’re proposing to do. Instead, you want to tell people that the old names are going away, by marking them as obsolete, without the alias.

Does that help?
~Chad


On 09 Jan 2014, at 07:21, Juanma Barranquero <lekktu@gmail.com> wrote:

> On Thu, Jan 9, 2014 at 4:08 PM, Eric S. Raymond <esr@thyrsus.com> 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
>