Bug#186102: version numbering for date-releases is flawed

[Russ Allbery <rra@debian.org>]

Josip Rodin <joy@srce.hr> writes:

> The Policy section "Version numbers based on dates" recommends using
> simply YYYYMMDD for versions based on dates.

> However, it is not uncommon for upstream authors to release date-based
> versions for betas, and then later switch to e.g. 1.0 for "proper"
> releases.  In such cases, people who used YYYYMMDD need to use epochs to
> switch to X.Y.

> This would be fixed by recommending to prepending additional zeros to
> YYYYMMDD. I would probably go for 0.0.YYYYMMDD. Someone else might want
> more?

The text referred to in this bug is section 3.2.1, which says:

     In general, Debian packages should use the same version numbers as the
     upstream sources.

     However, in some cases where the upstream version number is based on a
     date (e.g., a development "snapshot" release) the package management
     system cannot handle these version numbers without epochs.  For
     example, dpkg will consider "96May01" to be greater than "96Dec24".

     To prevent having to use epochs for every new upstream version, the
     date based portion of the version number should be changed to the
     following format in such cases: "19960501", "19961224".  It is up to
     the maintainer whether they want 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.

I agree that we shouldn't be recommending YYYYMMDD alone for upstream
snapshot releases for the reasons stated in the bug report.  The bug
report predates the introduction of ~, though, which now offers a better
solution to this problem than was available.

However, I think this whole bit really doesn't belong in Policy.  For
packages that are snapshot-based with no regular version number but one
that might show up later, I'd use 0~YYYYMMDD.  For ones that are
pre-releases, I'd use <new-version>~YYYYMMDD.  For ones that postdate an
existing version, I'd use <old-version>+YYYYMMDD.  But all of that feels
like best practices stuff.

Similarly, I'm not seeing why we should say YYYYMMDD should be used for
Debian native packages, as opposed to YYYY.MM.DD or some other format that
sorts properly.

I therefore think we should rewrite this whole section to remove most of
the details and instead just say not to ever use date-based formats like
96May01 and instead use something based off of YYYYMMDD, possibly with
punctuation (but not -).

If that sounds good, I can work on new language.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>