svn commit: r384872 - in head/security: . passivedns passivedns/files

[Alexey Dokuchaev]

On Tue, Apr 28, 2015 at 09:30:20PM +0200, Jan Beich wrote:
> Bryan Drewery <bdrewery at FreeBSD.org> writes:
> 
> > On 4/27/2015 3:33 PM, Lars Engels wrote:
> >
> >> +DISTVERSION=	${GH_TAG}
> > [...]
> >> +GH_TAG=		a6c7e26
> >
> > Actually this is not valid either. As soon as a new commit is done the
> > port may "go backwards".
> 
> > Commit hashses are not valid versions. Dates are.

Correct.  However, instead of using 2015xxyy one might want to prefix it
with something, e.g. 0.0.d2015xxyy to make it easy to switch to a "real"
version in the future.  Also see below.

> git describe --tags output is no worse than appending svn revision to
> the nearest tag. DISTFILES was already partially correct.
> 
>   $ pkg version -t 1.1.3 1.1.3-60
>   <
> 
> > A PORTEPOCH bump will be needed as well after fixing this.
> 
> Not really. bsd.port.mk assumes any letter as a pre-release suffix.
> 
>   # PORTVERSION=a6c7e26
>   $ pkg version -t a6c7e26 0
>   <
> 
>   # DISTVERSION=a6c7e26
>   $ pkg version -t a6.c7.e26 0

Using any part of hash as DISTVERSION is inherently bogus, no matter what
trick one might attempt to employ.  Versions increase monotonically, while
hashes are completely arbitrary (cannot be sorted to map to timeline).

> > For example:
> >
> > PORTVERSION= 20150428
> 
> Please, don't advise unprefixed dates. If one later wants to go back to
> a tag it'd require PORTEPOCH bump.

Correct; although some software might indeed use date as their version;
that is, they do not assume it will become 1.0 or anything sane in the
future.

All these issues happen because people often do not care enough to give
their stuff proper version numbers. :(  In these cases, it becomes our
(packagers) job to assign meaningful version number and think about the
room for expansion.

./danfe