Russ Allbery <[email protected]> writes:
> 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.
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>
--
Russ Allbery ([email protected]) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
