Auto rebuild release bump issue

[Michael Schwendt]

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.