Ben Hutchings <ben@decadent.org.uk> (30/04/2011): > --- > 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"> Seconded; thanks, Ben. Mraw, KiBi.
Attachment:
signature.asc
Description: Digital signature