Bug#852523: Central section commont to (old)stable and (old)stable-security regarding versioning recommendations
- To: email@example.com
- Subject: Bug#852523: Central section commont to (old)stable and (old)stable-security regarding versioning recommendations
- From: Salvatore Bonaccorso <firstname.lastname@example.org>
- Date: Wed, 25 Jan 2017 07:23:37 +0100
- Message-id: <[🔎] 20170125062337.GA18657@lorien.valinor.li>
- Reply-to: Salvatore Bonaccorso <email@example.com>, firstname.lastname@example.org
- In-reply-to: <email@example.com>
- References: <firstname.lastname@example.org> <20161201145444.GA9043@lorien.valinor.li> <email@example.com> <firstname.lastname@example.org> <20161202054018.GA11369@lorien.valinor.li> <email@example.com>
Since I failed to come up with a proper proposal for a formulation
let's open a bug for it. Part of the versioning recommendation is
already present in the developers-reference.
On Fri, Dec 02, 2016 at 08:57:14AM +0100, Emilio Pozuelo Monfort wrote:
> On 02/12/16 06:40, Salvatore Bonaccorso wrote:
> > Hi Emilio, Jonas, Antoine,
> > Thanks for all feedback.
> > On Thu, Dec 01, 2016 at 04:44:22PM +0100, Emilio Pozuelo Monfort wrote:
> >> On 01/12/16 16:25, Jonas Meurer wrote:
> >>> Hi Security and LTS folks,
> >>> Am 01.12.2016 um 15:54 schrieb Salvatore Bonaccorso:
> >>>> On Wed, Nov 30, 2016 at 04:05:20PM -0500, Antoine Beaupré wrote:
> >>>>> +nss (2:3.26.2-1+debu7u1) UNRELEASED; urgency=high
> >>>>> +
> >>>>> + * Non-maintainer upload by the LTS Security Team.
> >>>>> + * New upstream release to fix CVE-2016-9074
> >>>> Depending on what is done this should be either 2:3.26.2-0+debu7u1 or
> >>>> 2:3.26.2-1~debu7u1, but 2:3.26.2-1+debu7u1 is higher than 2:3.26.2-1.
> >>>> The former if you import new orig source on top of the previous
> >>>> packaging to indicate the new import and have a version which is
> >>>> before any possible such ones uploaded to unstable (which is even true
> >>>> in this case because 2:3.26.2-1 is currently in unstable). The later
> >>>> is often prefered if the package is mostly are build of :3.26.2-1 for
> >>>> Wheezy. (The later proposed version works obviously as well in the
> >>>> case of just a new upstream import, but Release team has often as well
> >>>> done that distinction for the ~debXuY suffix).
> >>> With this topic being discussed again and again recently, I suggest that
> >>> we should agree on a defined standard regarding the versioning of new
> >>> upstream releases uploaded to (old)?stable(-security)? and document it
> >>> somewhere. What do you think?
> >>> I don't have particular strong feelings on the exact versioning but I
> >>> think that the following should be considered:
> >>> *) New upstream releases in (old)?stable should use lover version
> >>> numbers than their equivalent uploaded to unstable. This because
> >>> packages uploaded to unstable are built using more recent versions
> >>> of the build toolchain and libraries.
> >> Moreover, New upstream releases should use lower versions than the next suite.
> >> That means oldstable < stable < testing < sid. Not just oldstable < sid and
> >> stable < sid, as you worded it.
> >> That's why 2:3.26.2-1+debu7u1 would be bad even if unstable had 2:3.26.3-1 by
> >> now, if stable had 2:3.26.2-1~debu8u1.
> >> When doing an update in oldstable, we need to see if it has happened or is
> >> happening in stable to avoid having a higher version in oldstable.
> >>> *) The versioning should make it obvious whether the new release is
> >>> based on a similar upload to unstable or whether it's packaged
> >>> solely for (old)?stable.
> >>> Consequently, the following (as already done for most uploads of new
> >>> releases to (old)?stable) is my suggestion:
> >>> *) Uploads of new upstream releases to (old)?stable that were packaged
> >>> for unstable before should use the '~debXu1' suffix to the version
> >>> number from unstable as they're basically backports of the package
> >>> from unstable.
> >>> *) Uploads of new upstream releases that were not packaged for unstable
> >>> yet or will never be, should use the '1.2.3-0+debXu1' format (given
> >>> that '1.2.3' is the upstream version.
> >> That's the current practice, yes. As Salvatore pointed out, that's also what the
> >> SRMs require for (old)stable uploads.
> >>> If we can agree on this, what would be the proper place to document it
> >>> for the future? Ideally, this should be mandatory for any uploads of new
> >>> upstream releases to the (old)?stable suites, be it to
> >>> (old)?stable-security, to stable-proposed-updates or to stable-updates.
> >> Probably the developers-reference, which already mentions the +debXuY syntax in
> >> various places (including the security updates section, 220.127.116.11 ), but
> >> doesn't mention ~debXuY for the case of backports.
> > Right it is spread around on various sections both for stable updates
> > and as well for security updates. Would it make sense to maybe add a
> > new section for handling versioning for (old)?stable(-securit)?
> > udpates, and then reference from both the security bug handling and
> > the stable-updates handling to it?
> Yes, I think that would make sense.
> > I do not have a wording right now for dev-ref, but I can look if I can
> > come up with something during the weekend (keep in mind though that it
> > will in any case need review, I'm not a native english speaker).
> Great! I'm not a native speaker either, but I'll happy to look at it.
> Maybe cc debian-release@ with the patch so the SRMs can look at it as well.
Emilio confirmed the current practice at as well from release team
point of view in:
It would be great if the version recommentations might be in some
central section wich could then be referenced from both stable- as
well security handling bugs sections.