I propose we change the release format for snapshot kernels.
Now we get e.g.:
kernel-2.6.23-0.89.rc2.git2.fc8
and I suggest instead:
kernel-2.6.23-0.rc2.git2.89.fc8
That is, put the spec file version number last, not first. This way, when
we forget to reset fedora_cvs_origin after a rebase, we don''t have to
wait
for the next kernel version to do it, just the next gitN.
We can''t make this change until 2.6.23 sails, since for rpm version
comparison rc* is < any [0-9].
--- kernel.spec 09 Aug 2007 13:45:09 -0700 1.72
+++ kernel.spec 09 Aug 2007 13:46:42 -0700
@@ -126,7 +126,7 @@ Summary: The Linux kernel (the core of t
%define rctag .rc0
%endif
%endif
-%define pkg_release 0.%{fedora_build}%{?rctag}%{?gittag}%{?buildid}%{?dist}
+%define pkg_release 0%{?rctag}%{?gittag}.%{fedora_build}%{?buildid}%{?dist}
%endif
# The kernel tarball/base version
On Thu, 2007-08-09 at 13:59 -0700, Roland McGrath wrote:> I propose we change the release format for snapshot kernels. > Now we get e.g.: > > kernel-2.6.23-0.89.rc2.git2.fc8 > > and I suggest instead: > > kernel-2.6.23-0.rc2.git2.89.fc8 > > That is, put the spec file version number last, not first. This way, when > we forget to reset fedora_cvs_origin after a rebase, we don''t have to wait > for the next kernel version to do it, just the next gitN. > > We can''t make this change until 2.6.23 sails, since for rpm version > comparison rc* is < any [0-9].Please don''t do this. The kernel package is finally compliant with the Fedora Packaging Guidelines and this change would break it again. The reason we prefix with the 0.# is to prevent versioning comparison madness. If you need to do a fast rebuild, append a .# after the %{?dist}. ~spot
On Thu, Aug 09, 2007 at 01:59:49PM -0700, Roland McGrath wrote: > I propose we change the release format for snapshot kernels. > Now we get e.g.: > > kernel-2.6.23-0.89.rc2.git2.fc8 > > and I suggest instead: > > kernel-2.6.23-0.rc2.git2.89.fc8 > > That is, put the spec file version number last, not first. This way, when > we forget to reset fedora_cvs_origin after a rebase, we don''t have to wait > for the next kernel version to do it, just the next gitN. Is it that big a deal? I intended to only reset the origin after each point release, so it doesn''t really buy us anything being able to change this with every -git. Dave -- http://www.codemonkey.org.uk
> > On Thu, 2007-08-09 at 13:59 -0700, Roland McGrath wrote: > > I propose we change the release format for snapshot kernels. > > Now we get e.g.: > > > > kernel-2.6.23-0.89.rc2.git2.fc8 > > > > and I suggest instead: > > > > kernel-2.6.23-0.rc2.git2.89.fc8 > > > > That is, put the spec file version number last, not first. This way, when > > we forget to reset fedora_cvs_origin after a rebase, we don''t have to wait > > for the next kernel version to do it, just the next gitN. > > > > We can''t make this change until 2.6.23 sails, since for rpm version > > comparison rc* is < any [0-9]. > > Please don''t do this. The kernel package is finally compliant with the > Fedora Packaging Guidelines and this change would break it again. > > The reason we prefix with the 0.# is to prevent versioning comparison > madness.What? I didn''t propose removing the 0. prefix. What is the problem?
> On Thu, Aug 09, 2007 at 01:59:49PM -0700, Roland McGrath wrote: > > I propose we change the release format for snapshot kernels. > > Now we get e.g.: > > > > kernel-2.6.23-0.89.rc2.git2.fc8 > > > > and I suggest instead: > > > > kernel-2.6.23-0.rc2.git2.89.fc8 > > > > That is, put the spec file version number last, not first. This way, when > > we forget to reset fedora_cvs_origin after a rebase, we don''t have to wait > > for the next kernel version to do it, just the next gitN. > > Is it that big a deal? I intended to only reset the origin after each > point release, so it doesn''t really buy us anything being able to change > this with every -git.It''s not a big deal, it''s only numbers. The motivation was that it didn''t get reset when we went from 2.6.22 to 2.6.23, and after one build hits rawhide, it''s too late. Also, it''s just better because it accurately reflects the topology of change. A spec release is a variant of a kernel snapshot, not vice versa.
On Thu, Aug 09, 2007 at 02:24:44PM -0700, Roland McGrath wrote: > > On Thu, Aug 09, 2007 at 01:59:49PM -0700, Roland McGrath wrote: > > > I propose we change the release format for snapshot kernels. > > > Now we get e.g.: > > > > > > kernel-2.6.23-0.89.rc2.git2.fc8 > > > > > > and I suggest instead: > > > > > > kernel-2.6.23-0.rc2.git2.89.fc8 > > > > > > That is, put the spec file version number last, not first. This way, when > > > we forget to reset fedora_cvs_origin after a rebase, we don''t have to wait > > > for the next kernel version to do it, just the next gitN. > > > > Is it that big a deal? I intended to only reset the origin after each > > point release, so it doesn''t really buy us anything being able to change > > this with every -git. > > It''s not a big deal, it''s only numbers. The motivation was that it didn''t > get reset when we went from 2.6.22 to 2.6.23, and after one build hits > rawhide, it''s too late. For rawhide, I don''t think it really matters too much. Dave -- http://www.codemonkey.org.uk
On Thu, Aug 09, 2007 at 02:21:47PM -0700, Roland McGrath wrote:> > > > On Thu, 2007-08-09 at 13:59 -0700, Roland McGrath wrote: > > > I propose we change the release format for snapshot kernels. > > > Now we get e.g.: > > > > > > kernel-2.6.23-0.89.rc2.git2.fc8 > > > > > > and I suggest instead: > > > > > > kernel-2.6.23-0.rc2.git2.89.fc8 > > > > > > That is, put the spec file version number last, not first. This way, when > > > we forget to reset fedora_cvs_origin after a rebase, we don''t have to wait > > > for the next kernel version to do it, just the next gitN. > > > > > > We can''t make this change until 2.6.23 sails, since for rpm version > > > comparison rc* is < any [0-9]. > > > > Please don''t do this. The kernel package is finally compliant with the > > Fedora Packaging Guidelines and this change would break it again. > > > > The reason we prefix with the 0.# is to prevent versioning comparison > > madness. > > What? I didn''t propose removing the 0. prefix. What is the problem?Look closer, there''s a `#´ in Tom''s reply, which is what you want to move away. Actually the 0. prefix is not neccessary it is a leftover from 3rd party techniques to indicate vendor hierarchies, but it''s difficult to knock out people''s head. The important bit is that by having the `#´ before the part-of-the- version-that-had-to-be-banned-to-the-release-tag-because-otherwise-the- version-would-not-properly-increment you become independent of any upstream versioning trickery. git/rc versioning is not that new, and who knows whether next year we''ll have pre/rc/gold/ga/pl madness in upstream sub-versioning. So please keep the buildtag as `#´ is often referred to before the part-of-the-version-that-had-to-be-banned -- Axel.Thimm at ATrpms.net
Axel Thimm wrote:> On Thu, Aug 09, 2007 at 02:21:47PM -0700, Roland McGrath wrote: >>> On Thu, 2007-08-09 at 13:59 -0700, Roland McGrath wrote: >>>> I propose we change the release format for snapshot kernels. >>>> Now we get e.g.: >>>> >>>> kernel-2.6.23-0.89.rc2.git2.fc8 >>>> >>>> and I suggest instead: >>>> >>>> kernel-2.6.23-0.rc2.git2.89.fc8 >>>> >>>> That is, put the spec file version number last, not first. This way, when >>>> we forget to reset fedora_cvs_origin after a rebase, we don''t have to wait >>>> for the next kernel version to do it, just the next gitN. >>>> >>>> We can''t make this change until 2.6.23 sails, since for rpm version >>>> comparison rc* is < any [0-9]. >>> Please don''t do this. The kernel package is finally compliant with the >>> Fedora Packaging Guidelines and this change would break it again. >>> >>> The reason we prefix with the 0.# is to prevent versioning comparison >>> madness. >> What? I didn''t propose removing the 0. prefix. What is the problem? > > Look closer, there''s a `#´ in Tom''s reply, which is what you want to > move away. Actually the 0. prefix is not neccessary it is a leftover > from 3rd party techniques to indicate vendor hierarchies, but it''s > difficult to knock out people''s head.It has nothing to do with any 3rd-party techniques in the case. The ''0.#'' instead of just ''#'' is so that we can rebase the release number to 1 on each new major kernel version, so the first released 2.6.23 kernel for fc8 will be 2.6.23-1.fc8. At least, that was my intention when I wrote this stuff up, and its how we''ve used it thus far. Of course, my initial thought had been it''d be nice to not even have the ''.#'' portion in there, since you get reasonably decent rpm ordering with just 0.rcX.gitY.fc8, but then if we end up doing a rebuild of the same git snap, you have to worry about it, but we don''t want to have to muck around with that manually. That being the case, putting it after the leading 0 for git snaps, automatically incremented over the period leading up to the next kernel release, in line with the packaging guidelines, made the most sense. -- Jarod Wilson jwilson@redhat.com
On Thu, Aug 09, 2007 at 11:22:08PM -0400, Jarod Wilson wrote:> >Actually the 0. prefix is not neccessary it is a leftover from 3rd > >party techniques to indicate vendor hierarchies, but it''s difficult > >to knock out people''s head. > > It has nothing to do with any 3rd-party techniques in the case. The > ''0.#'' instead of just ''#'' is so that we can rebase the release number to > 1 on each new major kernel version,It has everything to do with 3rd parties and the key element here is history: Many years ago we started to discuss the beginning of what today became the packaging guidelines in fedora.us. One element was what to do with packages that override the vendors'' (RHL 6.x/7.x at that time), especially when the vendor was shippijng foo-1 and one would like to use foo-3. So foo-3-0.whatever was considered as a hierachy solution to allow the vendor to catch up with the 3rd party package w/o the vendor having to coordinate build tags with the little 3rd party repos. In reality many foo-1 -> foo-3 upgrades were for foo-3 = some prerelease, so this idiom got confused for prepending a 0. to prereleases. So, "0." had a semantic wandering to land where it''s used now, and the beginnings were 3rd party techniques to auto-overide their own packages when the vendor would update his. </history_lesson> ;) There is nothing wrong with not using "0." to mark prereleases, it''s just Fedora legacy/tradition. I''m not a fan of resetting the build tag anyway. But whatever the "0." the important thing is that the build tag (`#´) remains in front even if today the sub-versioning scheme for the kernel looks like it would automatically happen to fit in rpmvercmp ordering. Another history lesson shows that once one thought a versioning style would settle and work it is "usefully" extended in a way as to break theis assumption ;) -- Axel.Thimm at ATrpms.net
Axel Thimm wrote:> On Thu, Aug 09, 2007 at 11:22:08PM -0400, Jarod Wilson wrote: >>> Actually the 0. prefix is not neccessary it is a leftover from 3rd >>> party techniques to indicate vendor hierarchies, but it''s difficult >>> to knock out people''s head. >> It has nothing to do with any 3rd-party techniques in the case. The >> ''0.#'' instead of just ''#'' is so that we can rebase the release number to >> 1 on each new major kernel version, > > It has everything to do with 3rd parties and the key element here is > history: Many years ago we started to discuss the beginning of what > today became the packaging guidelines in fedora.us. One element was > what to do with packages that override the vendors'' (RHL 6.x/7.x at > that time), especially when the vendor was shippijng foo-1 and one > would like to use foo-3. > > So foo-3-0.whatever was considered as a hierachy solution to allow the > vendor to catch up with the 3rd party package w/o the vendor having to > coordinate build tags with the little 3rd party repos. > > In reality many foo-1 -> foo-3 upgrades were for foo-3 = some > prerelease, so this idiom got confused for prepending a 0. to > prereleases. > > So, "0." had a semantic wandering to land where it''s used now, and the > beginnings were 3rd party techniques to auto-overide their own > packages when the vendor would update his. > </history_lesson> ;)Yes, there''s history behind why the "0." convention is in the packaging guidelines, but I still maintain that the 3rd-party history has/had zero bearing on the decision to use it in the kernel package.> There is nothing wrong with not using "0." to mark prereleases, it''s > just Fedora legacy/tradition. I''m not a fan of resetting the build tag > anyway.I think your distaste of resetting the build tag is the real sticking point here. The main reason for "0.<buildtag>" in pre-release versioning is because the majority of people *are* fans of resetting the build tag.> But whatever the "0." the important thing is that the build tag (`#´) > remains in front even if today the sub-versioning scheme for the > kernel looks like it would automatically happen to fit in rpmvercmp > ordering. Another history lesson shows that once one thought a > versioning style would settle and work it is "usefully" extended in a > way as to break theis assumption ;)True, true... rh9 -> fc1, fc6 -> f7... :) -- Jarod Wilson jwilson@redhat.com
Le jeudi 09 août 2007 à 14:24 -0700, Roland McGrath a écrit :> Also, it''s just better because it accurately > reflects the topology of change. A spec release is a variant of a kernel > snapshot, not vice versa.Good version ordering is more important than topology Snapshot names are not always ordered, Fedora shiped non-Linus kernels in the past (-ac...), etc -- Nicolas Mailhot