Hi,

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?

Hi,

 > Package: debian-policy Hi,

 > 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?

	I use the following scheme for my nightly CVS Gnus build:
UPSTREAM=5.9.00161
UVERSION=$UPSTREAM-0.CVS
VERSION=$UVERSION.$(date +%Y.%m.%d).

	So I add 0.SOME_THING.YYYYMMDD. I don't think we need two
 0's, do we?

	manoj

Well, I've seen people use 0.99 and similar versions, so I'd rather use two
zeros...

I have always read this policy as documenting how to write date as part
of version, not how to use (only) date as version.

It can be a useful tip to add in the policy, unless we decide that epoch
are not so evil. Notifying upstream of the problem should be advised
also. Probably upstream is able to understnad that releasing 20030201
before 1 can be confusing. Also upstream can tell you how many '0.' you
need.

One alternative is to use 0+YYYYMMDD as version, that sorts before  0.0

This looks more like a best practice than a policy, though.

Cheers,

It makes no mention of being partial. Even if your interpretation is
correct, the phrasing is still open to interpretation and should be fixed.

Yeah, I agree, but it's in the Policy Manual as it is...

Evil enough :)

Josip Rodin <joy@srce.hr> writes:

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.

Agreed.

Sounds good to me.

Cheers,
Julien

Russ Allbery <rra@debian.org> writes:

Here's a proposal that tries to implement that.  Objections or seconds?

Someone may want to follow up with a patch to the devref to provide more
details about when to choose what form of a version number and how to use
~ appropriately.

diff --git a/policy.sgml b/policy.sgml
index ec1acee..acef23b 100644
--- a/policy.sgml
+++ b/policy.sgml
@@ -849,36 +849,30 @@

 	  <p>
 	    In general, Debian packages should use the same version
-	    numbers as the upstream sources.
-	  </p>
-
-	  <p>
-	    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".
+	    numbers as the upstream sources.  However, upstream version
+	    numbers based on some date formats (sometimes used for
+	    development or "snapshot" releases) will not be ordered
+	    correctly by the package management software.  For
+	    example, <prng>dpkg</prng> will consider "96May01" to be
+	    greater than "96Dec24".
 	  </p>

 	  <p>
 	    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.
-	  </p>
-
-	  <p>
-	    Note that other version formats based on dates which are
-	    parsed correctly by the package management system should
-	    <em>not</em> be changed.
+	    version, the date-based portion of any upstream version number
+	    should be given in a way that sorts correctly: four-digit year
+	    first, followed by a two-digit numeric month, followed by a
+	    two-digit numeric date, possibly with punctuation between the
+	    components.
 	  </p>

 	  <p>
-	    Native Debian packages (i.e., packages which have been
-	    written especially for Debian) whose version numbers include
-	    dates should always use the "YYYYMMDD" format.
+	    Native Debian packages (i.e., packages which have been written
+	    especially for Debian) whose version numbers include dates
+	    should also follow these rules.  If punctuation is desired
+	    between the date components, remember that hyphen (<tt>-</tt>)
+	    cannot be used in native package versions.  Period
+	    (<tt>.</tt>) is normally a good choice.
 	  </p>
 	</sect1>

Thanks Russ, seconded.

Cheers,
Julien

(what an old bug ;))

Russ Allbery <rra@debian.org> (16/07/2010):

Seconded.

Mraw,
KiBi.

Seconded.

Russ Allbery <rra@debian.org> writes:

This has been merged for the next release.

I'm going to clone and reassign this bug to developers-reference for this.

reassign 589478 debian-policy
forcemerge 1135785 589478
thanks

alright, reassigning and force merging accordingly. thanks!