Re: Versioning of new releases in (old)stable (Was: nss security update package ready for review)
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, 5.8.5.4 [1]), 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?
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).
Regards,
Salvatore
Reply to: