`No strings in PORTVERSION' (non-)limitation

[Dmitry Marakasov]

Hi!

There are software versions like, say, 1.1.git20120515, 1.1.beta2, 1.1.rc1

Historically, there have been a `limitation' of not using strings
(e.g. two or more consecutive letters) in PORTVERSION. Such versions
were to put into DISTVERSION instead of PORTVERSION, and the latter
will be generated by port.mk automatically by replacing strings
with their first letters (and doing some other mangling), so above
mentioned versions will become correspondingly 1.1.g20120515, 1.1.b2,
1.1.r1.

I wondered what is the reason for such a limitation, and so far no
one could answer me (at least or #bsdports). I still want to know
the reason, or, if there's actually none, we may consider removing
the limitation at all.

The limitation seems to be quite virtual as it is, as strings in
portversions are already handled without problems, I can't find any
mention of it in the porter's handbook and the only ones who remember
it seems to be us committers and portlint. Which is even more strange,
portlint makes exception for /pl[0-9]*/ for some reason:

if ($portversion =~ /^pl[0-9]*$/ || $portversion =~ /^[0-9]*[A-Za-z]?[0-9]*(\.[0-9]*[A-Za-z]?[0-9+]*)*$/) {
    # PORTVERSION is OK

First, non-reason for this limitation:
- Strings will be handled incorrectly
They are handled exactly like letters. pkg_version -t which we use to
compare versions actually doesn't distinct between f and foo, that is -
it already does a same thing as port.mk's DISTVERSION->PORTVERSION
mangling which shortens strings to the first letters.

As letters are handled nicely (including 1 < 2.a < 2 rule, which is
very useful for 1 -> 2.beta-> 2), so strings will be.

And resons for removing it:
- No real reasons to have it (?)
- It's not documented (or did I miss it?)
- Some ports already use strings (and nothing become broken):

/usr/ports/databases/sybtcl/Makefile:PORTVERSION=	3.0rc2
/usr/ports/devel/py-diazo/Makefile:PORTVERSION=	1.0rc4
/usr/ports/dns/bind96/Makefile:PORTVERSION=	9.6.3.1.ESV.R6
/usr/ports/games/xchomp/Makefile:PORTVERSION=	pl1
/usr/ports/graphics/linux-gdk-pixbuf/Makefile:PORTVERSION=	0.22.0.18.fc4.2
/usr/ports/japanese/xgate/Makefile:PORTVERSION=	3.7pl6
/usr/ports/java/jboss5/Makefile:PORTVERSION=	5.1.0.GA
/usr/ports/korean/hpscat/Makefile:PORTVERSION=	1.3jshin
/usr/ports/multimedia/linux-f10-libtheora/Makefile:PORTVERSION=	1.0rc1
/usr/ports/net/c3270/Makefile:PORTVERSION=	3.3.12ga7
/usr/ports/news/cnews/Makefile:PORTVERSION=	cr.g
/usr/ports/news/husky-msged/Makefile:PORTVERSION=	6.2RC1
/usr/ports/print/xdvi/Makefile:PORTVERSION=	pl20
/usr/ports/x11-wm/amiwm/Makefile:PORTVERSION=	0.21.pl2
/usr/ports/x11-wm/tvtwm/Makefile:PORTVERSION=	pl11

- Mangled version numbers are not informative. Judging by package
  version, there's no way to tell if an application just uses letters
  as a part of its version (like openssl, for example), or you've
  happened to have alpha/beta/rc or vcs snapshot of a software,
  which you'll most likely want to update to a proper release as
  soon as it's available
- Less confusion in ports as in many cases extra entity can be avoided

So, if we need this limitation, reason should be given, it should be
documented, and listed ports fixed. Otherwise, portlint should be fixed
and we should all march into the bright future of informative version
numbers :)

-- 
Dmitry Marakasov   .   55B5 0596 FF1E 8D84 5F56  9510 D35A 80DD F9D2 F77D
amdmi3 at amdmi3.ru  ..:  jabber: amdmi3 at jabber.ru    http://www.amdmi3.ru