Bug#248618: Section 3.2.1 encourages use of epochs
On Wed, May 12, 2004 at 02:15:29PM +0200, Robert Millan wrote:
> Ironicaly, using the "YYYYMMDD" scheme grants us an epoch whenever upstream
> decides to use a normal version number. I propose the following scheme
> instead:
>
> "0.0.0+YYYYMMDD[.X]" for snapshots without a previous release.
> "A.B.C+YYYYMMDD[.X]" for snapshots after release "A.B.C".
>
> (where optional .X is an unsigned integer)
What is wrong with an epoch? I find '0.0.0+20040512' quite ugly.
> It should be also noted that many programs violate the versioning scheme
> (both current and my proposed one) by adding the "cvs" string to the version
> number (e.g. "A.B.C+cvsYYYYMMDD"). When upstream decides to migrate to another
> RCS, this could lead to an epoch:
>
> "A.B.C+cvsYYYYMMDD" -> "A.B.C+svnYYYYMMDD" (ok)
> "A.B.C+cvsYYYYMMDD" -> "1:A.B.C+archYYYYMMDD" (bad)
>
> This is already a violation, but I propose that Policy lists it explicitly
> as such to avoid errors.
Good point when there is no actual version, but if there is, I see no
real problem. Change in VCS don't happen often, and it emphasises the
fact it is an unstable, unreleased version.
But a different identification, that isn't VCS-specific, like
'unreleased20040512' or 'trunk20040512' might be preferable (in the
latter case it is a bit specific though...). I think the current
practice is usually okay in this regard, it cannot hurt to be a bit more
verbose in policy about this.
Regards,
--Jeroen
--
Jeroen van Wolffelaar
Jeroen@wolffelaar.nl (also for Jabber & MSN; ICQ: 33944357)
http://Jeroen.A-Eskwadraat.nl
Reply to: