Package: developers-reference Version: 3.4.18 Hi
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, 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? > > 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. > > Cheers, > Emilio Emilio confirmed the current practice at as well from release team point of view in: https://lists.debian.org/debian-lts/2016/12/msg00013.html 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. Regards, Salvatore
