Bug#685646: Please advise a reliable version scheme for {stable,testing}{,-security}
Package: developers-reference
Version: 3.4.9
Severity: normal
Tags: patch
Hi,
As discussed on #d-release, the version scheme advice could be improved,
so should the distribution declared in changelog, for the testing and
{old,}stable upload (including the -security ones), in order to have
only one scheme to rule them all.
The attached patch tries to address the version scheme part, updating
the nmu-changelog part — second hunk of the diff — (maybe this part
could be move in a less NMU-centric part of the doc), and advise to use
the distribution name in changelog instead of {oldstable,stable,testing}
in the two other hunks. English should probably be improved, and more
invasive change to avoid the stable, stable-update,
stable-proposed-update and stable-security advised in the text, but
-release and -security are X-CCed to either ACK the proposal or reword
it first.
Extract of the IRC log:
15:27 < KiBi> do we prefer 0.8.0~rc1-8.1 or 0.8.0~rc1-8+wheezy1 for an
NMU to tpu?
15:27 < adsb> I'd tend towards +wheezy1. I'd unblock either though
15:27 < KiBi> me too. ta
[…]
15:31 < KiBi> Oops I forgot again: do we prefer testing,
testing-proposed-updates, or the respective codenamish counterparts?
15:31 < KiBi> I think one wins by a slight margin, but..
[…]
15:58 < taffit> KiBi: Should I better go with 0.8.0~rc1-8wheezy1
(without “+”)? If “+” is better, I can propose a patch to the dev-ref.
(Tell me if you prefer testing-proposed-updates too).
15:59 < adsb> + is nicer, because it sorts above binNMUs (until we name
a release starting with "a", anyway)
[…]
16:16 < phil> adsb: Shouldn't we go with the new version scheme now?
16:16 < phil> Instead of establishing +wheezy precedents. (Yeah, they
probably exist already.)
16:17 < adsb> phil: point. need to get my brain trained to remember
that scheme
16:17 < phil> If you upload a package to testing or stable, you
sometimes need to "fork" the version number tree. This is the case for
security uploads, for example. For this, a version of the form +debXYuZ
should be used, where X and Y are the major and minor release numbers,
and Z is a counter starting at 1.
16:17 < phil> That's the right devref bit.
[…]
16:19 < _rene_> ugh, deb70u1?
16:19 < phil> And yes the "nmu-changelog" sucks as a section title.
[…]
16:28 < adsb> iirc we were debating getting it changed to drop the 0,
given that the minor will always be 0
16:28 < adsb> phil: any strong preference, before we create precedent?
:)
16:29 < phil> I wouldn't mind +deb7u1. +deb8something would sort higher
anyway. Just +deb7Z with Z being the counter would've been weird.
[…]
16:30 < taffit> couldn't the 0 be a one for a new kernel (à la
etch_and_a_half)?
[…]
16:31 < adsb> I'm not sure if we'd do a -nhalf again; we're more liberal
about what we accept in terms of kernel changes for hardware etc now
[…]
16:32 < adsb> it's only as binding as we make it, in any case
16:32 < adsb> I prefer +deb7u1 from an aesthetic pov, fwiw
16:33 < phil> Then that's what it is.
16:33 < adsb> the version number discussion in the tpu section should
probably just go away and be replaced by a pointer to the other one
16:33 < phil> But we should tell $security.
16:33 < adsb> and of course jmm's not here
16:34 < adsb> will mail
[…]
16:37 < taffit> +deb7u1 for an NMU, and +wheezy1 for a maintainer
upload?
16:37 < taffit> (that would be weird to I guess)
16:37 < phil> Nope, the former for both.
16:38 < adsb> for stable we don't really care whether it's an NMU,
security update or MU via p-u. it's just a stable update
[ Back to testing vs. codename ]
16:41 < adsb> KiBi: taffit: fwiw, at least until I change my mind I'd
say $c > $c-p-u > t > tpu
[…]
16:44 < adsb> using the codename everywhere would have saved a bit of
pain with e.g. security updates which were prepared for lenny-as-stable
but not published until after the squeeze release for some reason; there
were a few of those that had to be rebuilt just to change the
distribution if my memory isn't entirely failing me
[…]
16:46 < adsb> at least the multi-archive changes mean the upload
signature is now only checked once, so the key expiry foo goes away
Regards
David
-- System Information:
Debian Release: wheezy/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.2.0-3-amd64 (SMP w/1 CPU core)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
developers-reference depends on no packages.
Versions of packages developers-reference recommends:
ii debian-policy 3.9.3.1
Versions of packages developers-reference suggests:
ii doc-base 0.10.4
-- no debconf information
Index: pkgs.dbk
===================================================================
--- pkgs.dbk (révision 9331)
+++ pkgs.dbk (copie de travail)
@@ -370,6 +370,12 @@
long as it hasn't been archived. The same rules as for <literal>stable</literal>
apply.
</para>
+<para>
+Version numbers should follow advice from <xref linkend="nmu-changelog"/>, and
+the distribution name should be preferred over <literal>stable</literal> or
+<literal>oldstable</literal> in the changelog entry.
+</para>
+
</section>
<section id="upload-t-p-u">
@@ -2094,21 +2100,20 @@
If you upload a package to testing or stable, you sometimes need to "fork" the
version number tree. This is the case for security uploads, for example. For
this, a version of the form
-<literal>+deb<replaceable>XY</replaceable>u<replaceable>Z</replaceable></literal>
-should be used, where <replaceable>X</replaceable> and
-<replaceable>Y</replaceable> are the major and minor release numbers, and
+<literal>+deb<replaceable>X</replaceable>u<replaceable>Z</replaceable></literal>
+should be used, where <replaceable>X</replaceable>
+is the major and minor release numbers, and
<replaceable>Z</replaceable> is a counter starting at <literal>1</literal>.
When the release number is not yet known (often the case for
<literal>testing</literal>, at the beginning of release cycles), the lowest
release number higher than the last stable release number must be used. For
-example, while Lenny (Debian 5.0) is stable, a security NMU to stable for a
+example, while Squeeze (Debian 6.0) is stable, a security NMU to stable for a
package at version <literal>1.5-3</literal> would have version
-<literal>1.5-3+deb50u1</literal>, whereas a security NMU to Squeeze would get
-version <literal>1.5-3+deb60u1</literal>. After the release of Squeeze, security
+<literal>1.5-3+deb6u1</literal>, whereas a security NMU to Wheezy would get
+version <literal>1.5-3+deb7u1</literal>. After the release of Wheezy, security
uploads to the <literal>testing</literal> distribution will be versioned
-<literal>+deb61uZ</literal>, until it is known whether that release will be
-Debian 6.1 or Debian 7.0 (if that becomes the case, uploads will be versioned
-as <literal>+deb70uZ</literal>).
+<literal>+deb8u<replaceable>Z</replaceable></literal> since Jessie will be
+Debian 8.0.
</para>
</section>
@@ -2689,11 +2694,10 @@
<literal>unstable</literal> does not pull in any new dependencies.
</para>
<para>
-Version numbers are usually selected by adding the codename of the
-<literal>testing</literal> distribution and a running number, like
-<literal>1.2squeeze1</literal> for the first upload through
-<literal>testing-proposed-updates</literal> of package version
-<literal>1.2</literal>.
+<para>
+Version numbers should follow advice from <xref linkend="nmu-changelog"/>, and
+the distribution name should be preferred over <literal>testing</literal> in
+the changelog entry.
</para>
<para>
Please make sure you didn't miss any of these items in your upload:
Reply to: