Bug#248618: Section 3.2.1 encourages use of epochs
Package: debian-policy
Version: 3.6.1.0
Severity: normal
The following text may be read in section 3.2.1:
To prevent having to use epochs for every new upstream version, the
version number should be changed to the following format in such
cases: "19960501", "19961224". It is up to the maintainer whether
he/she wants to bother the upstream maintainer to change the version
numbers upstream, too.
Note that other version formats based on dates which are parsed
correctly by the package management system should not be changed.
Native Debian packages (i.e., packages which have been written
especially for Debian) whose version numbers include dates should
always use the "YYYYMMDD" format.
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)
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.
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.4.26-1-k7
Locale: LANG=C, LC_CTYPE=C
-- no debconf information
Reply to: