Re: Tag cleanup

["Eric S. Raymond" <esr@thyrsus.com>]

Eli Zaretskii <eliz@gnu.org>:
> I think everything except EMACS_PRETEST_* and emacs-xx.yy (why the
> different letter-case and syntax, btw?) should be removed. 

The tags beginning eith uppercase EMACS and containing _ where you would
expect . are inherited CVS tags; . was not a legal tag character in CVS.

After the switchover to bzr, whover was making release tags (probably Stefan) 
started using the more natural emacs-xx.yy convention, but did not rename
the old tags.

I renamed the old CVS-style release tags to corresponding emacs-xx.yy
tags because my philosophy about conversions is to use the idioms of the
target VCS wherever possible, making the join between older and newer
portions of the history invisible.

I didn't rename the *PRETEST* tags because I wasn't sure we'd keep them.
I agree with you that if we keep them they would be better renamed 
something like emacs-pretest-xx.yy.zz.

>                                                          Those
> other tags are of no importance once the corresponding features have
> landed on mainline.  For example, emacs-bidi-base can certainly go.

The *-base tags are almost certainly automatically generated CVS
artifacts that can be removed, but I am conservative by habit in
making such changes.

> But please wait for the "owners" of those other tags to speak up, I
> don't want to usurp anyone's tags.

I don't either.

> The fate of the pretest tags depends on whether we will continue using
> such tags in the future.  Emacs pretests are normally quite long, so a
> pretest emacs-24.3.90 is very similar to a released version, and the
> number of commits between it and the next pretest will generally be
> very large.  So, if the git experts say that "git describe" and its
> middle field are important, I'd rather see there a small enough number
> than something of 6 digits.

We have two policy questions:

1. Continue using pretest tags?  If so, I will rename as you suggest.  
If not, I will delete them. I have no strong preference here.

2. What form do we intend to use for the value of
emacs-repository-version?  The choices are raw SHA1 or git describe
format; others are theoretically possible but it is normal git
practice to choose one of those two.  I advocate the latter as I think
the format is more informative to humans.

These are not my decisions to make unless everybody yawns and says
"don't care".  I would much prefer to see a list consensus or, failing
that, maintainer fiat.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>