On Sat, 23 Feb 2008 11:38:17 +0000 (UTC), Kevin Kofler wrote: > > Also added in cvs is a fallback, where a release string that doesn't > > match at all is tried to be bumped at the very right, and if that > > is not possible, ".1" is appended. > > Are you sure you want to autobump Release entries which don't match any of the > templates in the guidelines? Some numbers from a couple of background test-runs with rawhide cvs: 5472 spec files use an ordinary "Release:" tag close to the guidelines 10 spec files do "%define release ..." or "%define RELEASE ..." 6 spec files do "%define rel ..." 19 spec files do "Release: %release_func ..." 1 spec file does "%define baserelease ..." ~38 spec files are macro-overloaded beyond recognition, a few of them even pull %version and %release from %SOURCE1 using awk Of the 5472, some get the pre-release versioning scheme wrong or use lots of macros to make it less readable (also for any security response team people who may need to touch something like that), e.g. ghdl.spec : 0.%{ghdlsvnver}svn.7%{?dist} ochusha.spec : 0.%{vendor_rel}.%{strtag}%{?dist} gnome-mount.spec : 0.svn20080225.4%{?dist} libapreq2.spec : 0.rc2.14%{?dist} *eewh*: %define rel %{?minorver:0.}%{fedorarel}%{?minorver:.%minorver} *ouch*: gdm.spec -0.2008.02.29.3%{?dist} +0.2009.02.29.3%{?dist} Stuff appended right of the dist-tag could be recognised and deleted to be less ugly, cups-pdf.spec -6%{?dist}.2 +7%{?dist}.2 but then the bumper would still not round to integer values in corner-cases like crash.spec -6.0.5 +7.0.5 because the context of the least-significant numbers is unknown. -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list