---
This is based on recent discussions on debian-devel. There was not
complete agreement, but I believe this reflects consensus.
Ben.
policy.sgml | 23 +++++++++++++++++++++++
1 files changed, 23 insertions(+), 0 deletions(-)
diff --git a/policy.sgml b/policy.sgml
index 91173a5..2cc2d1e 100644
--- a/policy.sgml
+++ b/policy.sgml
@@ -934,6 +934,29 @@
</p>
</sect1>
+ <sect1>
+ <heading>Version numbers based on revision IDs</heading>
+
+ <p>
+ If the upstream version is a snapshot from a version
+ control system, the upstream version number may
+ incorporate a linear revision ID from the version control
+ system. For example, a Subversion or Mercurial revision
+ ID can be used if all snapshots are taken from the same
+ repository and branch. A commit count from <prgn>git
+ describe</prgn> output can be used if all snapshots are
+ taken from the same branch which is not rebased or
+ otherwise rolled back.
+ </p>
+ <p>
+ The upstream version number must not include a non-linear
+ revision ID or hash, since it cannot help in ordering
+ versions and it tends to result in very long version
+ numbers and filenames. This information may be recorded
+ in the changelog instead.
+ </p>
+ </sect1>
+
</sect>
<sect id="maintainer">
--
1.7.4.4
--
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.
Attachment:
signature.asc
Description: This is a digitally signed message part