Please remove the following email address:  e.little...@gmail.com

On Sun, Sep 10, 2023 at 7:31 PM Debian Bug Tracking System <
ow...@bugs.debian.org> wrote:

> Your message dated Sun, 10 Sep 2023 16:26:20 -0700
> with message-id <87y1hdtxsz....@hope.eyrie.org>
> and subject line Re: Bug#877697: debian-policy: discourage using all 4
> digits numbers in Standards-Version
> has caused the Debian Bug report #877697,
> regarding debian-policy: discourage using all 4 digits numbers in
> Standards-Version
> to be marked as done.
>
> This means that you claim that the problem has been dealt with.
> If this is not the case it is now your responsibility to reopen the
> Bug report if necessary, and/or fix the problem forthwith.
>
> (NB: If you are a system administrator and have no idea what this
> message is talking about, this may indicate a serious mail system
> misconfiguration somewhere. Please contact ow...@bugs.debian.org
> immediately.)
>
>
> --
> 877697: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=877697
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>
>
>
> ---------- Forwarded message ----------
> From: Mattia Rizzolo <mat...@debian.org>
> To: sub...@bugs.debian.org
> Cc:
> Bcc:
> Date: Wed, 4 Oct 2017 15:30:37 +0200
> Subject: debian-policy: discourage using all 4 digits numbers in
> Standards-Version
> Package: debian-policy
> Version: 4.1.1.0
>
> Policy § 5.6.11, after describing the meaning of the digits in the
> policy version, reads:
>
> | Thus only the first three components of the policy version are
> | significant in the Standards-Version control field, and so either
> | these three components or all four components may be specified. [5]
>
>
> Now, I've only got the impressions that packages should avoid using the
> 4th digit in their Standards-Version field, as that number has no
> meaning when it comes to normative stuff.  I've seen on IRC/MLs all kind
> of comments saying that the 4th digit should be avoided, and most
> packages avoid it indeed, but this wording in the policy makes me feel
> like it's pretty much the same.
>
> --
> regards,
>                         Mattia Rizzolo
>
> GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540      .''`.
> more about me:  https://mapreri.org                             : :'  :
> Launchpad user: https://launchpad.net/~mapreri                  `. `'`
> Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-
>
>
>
> ---------- Forwarded message ----------
> From: Russ Allbery <r...@debian.org>
> To: Mattia Rizzolo <mat...@debian.org>
> Cc: 877697-d...@bugs.debian.org
> Bcc:
> Date: Sun, 10 Sep 2023 16:26:20 -0700
> Subject: Re: Bug#877697: debian-policy: discourage using all 4 digits
> numbers in Standards-Version
> Mattia Rizzolo <mat...@debian.org> writes:
>
> > Policy § 5.6.11, after describing the meaning of the digits in the
> > policy version, reads:
>
> > | Thus only the first three components of the policy version are
> > | significant in the Standards-Version control field, and so either
> > | these three components or all four components may be specified. [5]
>
> > Now, I've only got the impressions that packages should avoid using the
> > 4th digit in their Standards-Version field, as that number has no
> > meaning when it comes to normative stuff.  I've seen on IRC/MLs all kind
> > of comments saying that the 4th digit should be avoided, and most
> > packages avoid it indeed, but this wording in the policy makes me feel
> > like it's pretty much the same.
>
> After some discussion of this six years ago, it doesn't look like there
> was any consensus to change Policy here.  Most people only use three
> numbers.  Some people prefer to use four numbers to make it very clear
> what version of Policy they looked at, and just in case informative
> updates were relevant (probably a bug in Policy if that happens, but maybe
> not).
>
> I think it's therefore fine to use either, which is what Policy says now,
> so I'm going to close this bug.
>
> --
> Russ Allbery (r...@debian.org)              <https://www.eyrie.org/~eagle/>

Reply via email to