Clarified NMU versioning to reflect existing practices. Closes: #532945

[developers-reference.git] / pkgs.dbk

diff --git a/pkgs.dbk b/pkgs.dbk
index e9b058a3e2486f6fa535671aedb3705c08bfad3c..160fa5b11a08fdd1a80ebd4e05bad81eb3e3c6f4 100644 (file)
--- a/pkgs.dbk
+++ b/pkgs.dbk
@@ -48,6 +48,12 @@ new package in order for the bug report to be automatically closed once the new
 package is installed in the archive (see <xref linkend="upload-bugfix"/> ).
 </para>
 <para>
+If you think your package needs some explanations for the administrators of the
+NEW package queue, include them in your changelog, send to ftpmaster@debian.org
+a reply to the email you receive as a maintainer after your upload, or reply to
+the rejection email in case you are already re-uploading.
+</para>
+<para>
 When closing security bugs include CVE numbers as well as the Closes: #nnnnn.
 This is useful for the security team to track vulnerabilities.  If an upload is
 made to fix the bug before the advisory ID is known, it is encouraged to modify
@@ -1784,6 +1790,16 @@ also enable Debian to recompile entire distributions quickly.
 The buildds admins of each arch can be contacted at the mail address
 <literal><replaceable>arch</replaceable>@buildd.debian.org</literal>.
 </para>
+
+<para>
+Since the Release team also has access to wanna-build,
+it has become common practice to ask them to perform actions such as
+the recompilation of packages (binNMUs, see <xref linkend="binary-only-nmu"/>)
+or the retry of failed builds (give-backs).
+The format to use when requesting such actions is described at
+<ulink url="&url-release-wb;"/>.
+</para>
+
 </section>
 
 </section>
@@ -1983,18 +1999,33 @@ upload.  The first line of this entry must explicitely mention that this upload
 </screen>
 
 <para>
-The version must be the version of the last maintainer upload, plus
+The way to version NMUs differs for native and non-native packages.
+</para>
+<para>
+If the package is a native package (without a debian revision in the version number), 
+the version must be the version of the last maintainer upload, plus
 <literal>+nmu<replaceable>X</replaceable></literal>, where
-<replaceable>X</replaceable> is a counter starting at <literal>1</literal>.  If
+<replaceable>X</replaceable> is a counter starting at <literal>1</literal>.
+If
 the last upload was also an NMU, the counter should be increased.  For example,
-if the current version is <literal>1.5-1</literal>, then an NMU would get
-version <literal>1.5-1+nmu1</literal>.  If the current version is
-<literal>1.5+nmu3</literal> (a native package which has already been NMUed), the
-NMU would get version <literal>1.5+nmu4</literal>.  If a new upstream version
+if the current version is <literal>1.5</literal>, then an NMU would get
+version <literal>1.5+nmu1</literal>.
+</para>
+<para>
+If the package is a not a native package, you should add a minor version number
+to the debian revision part of the version number (the portion after the last
+hyphen). This extra number must start at 1.  For example,
+if the current version is <literal>1.5-2</literal>, then an NMU would get
+version <literal>1.5-2.1</literal>. If a new upstream version
 is packaged in the NMU, the debian revision is set to <literal>0</literal>, for
-example <literal>1.6-0+nmu1</literal>.
+example <literal>1.6-0.1</literal>.
+</para>
+<para>
+In both cases, if the last upload was also an NMU, the counter should
+be increased. For example, if the current version is
+<literal>1.5+nmu3</literal> (a native package which has already been
+NMUed), the NMU would get version <literal>1.5+nmu4</literal>.  .
 </para>
-
 <para>
 A special versioning scheme is needed to avoid disrupting the maintainer's
 work, since using an integer for the Debian revision will potentially