DEP14 policy for two dots

[Ian Jackson]

Raphael Hertzog writes ("Re: DEP14 policy for two dots"):
> On Fri, 04 Nov 2016, Ian Jackson wrote:
> > My proposal is reversible.  It does not need to be extensible.
> 
> So what about "..."? Would it give ".#.#."?

Yes.  I said (fixing my bug):

 > Insert "#":
 >    - between each pair of adjacent dots
 >    - after any trailing dot
 >    - before any leading dot
      - after the `.' of a trailing `.lock'

The latter is necessary because git reserves .lock.  (!)
The summary is `add # after any troublesome dot' (discounting leading
dots which you say are now illegal in Debian).

I'm running some exhaustive tests to check that this rule is
sufficient, because I'm not sure I trust the git docs.

> What's the rule to apply? if it's just to drop the "#", then yes
> it's reversible in a single step. If it's "s/\.#\./../g" then you need
> to do it multiple times until you no longer find ".#.".

The reverse rule is to convert _ and % and delete all #.

> > > My suggestion would be to allow "#<hexadecimal unicode code point>#". 
> > > Thus my personal preference would be to replace ".." with ".#2e#".
> > 
> > This is a bad idea because it (implicitly) makes the conversion
> > nondeterministic.
> 
> We define the conversion rule in DEP-14. We can define it in a
> deterministic way.

If you define it in a deterministic way then it is by definition not
extensible, because all valid version strings have a definitive git
tag representation.

Unless by `extensible' you mean `we can update the rule if we discover
that some of the specified git tag representations are not accepted by
git', or `we can update the rule if the set of valid Debian version
strings is extended'.  But this is true of any proposal, no matter
what the syntax is.

> I wanted something extensible because what's allowed in git ref names
> might evolve. It would not be the first time that a special syntax
> is introduced with a new feature.

I think the git folks are going to try not to further restrict the git
ref name syntax.  After all, if they do restrict it, what about
existing tags with the now-forbidden names ?

> Which of # or = is more likely to be used for a new syntax/feature in git?
> My bet would go for "#" so that "=" is an even better choice.

I think = is more likely to be used for other things (both by git and
by others).

Ian.

-- 
Ian Jackson <ijackson at chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.