Re: Bad version number based on date advice in policy?
Peter S Galbraith <p.galbraith@globetrotter.net> wrote:
>
>> And somehow 0.YYYYMMDD is more elegant or requires less explanation?
>
> Absolutely. It's _one_ number, and people can easily understand it's
> less than unity. (A lot of upstream versions numbers that have dates
> have them because upstream doesn't feel the software to be ready to be
> called 1.0)
I won't start a discussion of whether 1:1.0 can be treated as a number
or not :)
However, epochs are designed so that they only need to be shown where
it is necessary to establish the aboslute order between two arbitrary
version numbers.
That is, in any context where such comparisons are not necessary, it
is permissible for the epoch to be hidden. In fact, some of our tools
already do that. For example, you won't find any epochs in the filenames
in the archive pool. This applies equally to most interfaces with the
user. Unfortunately not all the tools today hide the epoch in every
place where it is possible, but that is something that can be addressed.
On the otherhand, any attempt to avoid an epoch results in a
mutilation of the version number that is at least as horrific.
Worse yet, such a mutilation cannot be hidden from the user
systematically.
Some may argue that such mutilations are only temporary. Well I must
say that in the contexts that I've seen it used, it is not obvious
that their existence over the lifetime of a package will be
significantly less compared to the that of an epoch if it were used.
In this particular instance, it is not obvious whether a package
will spend most of its life as YYYYMMDD or X.Y until that switch
has been made.
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Reply to: