[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Auto rebuild release bump issue



On Sat, 23 Feb 2008 11:38:17 +0000 (UTC), Kevin Kofler wrote:

> Michael Schwendt <mschwendt <at> gmail.com> writes:
> > 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? They could contain really anything, e.g. hardcoded 
> disttags, which "bumping at the very right" could accidentally turn from .fc9 
> into .fc10, or some other unforeseeable weird stuff.

1) Hardcoded disttags are not permitted in Fedora, afaik.

2) How weird (and in violation of the guidelines) would a release value
need to be before the script fails to match at all?

I don't talk about some of the "got it almost right" cases here, such as:

  $ bumpspecfile.py testinvalid1.spec
  WARNING: Bad pre-release versioning scheme!
  testinvalid1.spec
  -0.rc2%{?dist}
  +0.rc2%{?dist}.1

  $ bumpspecfile.py testinvalid1.spec
  WARNING: Bad pre-release versioning scheme!
  testinvalid1.spec
  -0.rc2%{?dist}.1
  +0.rc2%{?dist}.2

Or:

  $ bumpspecfile.py testcvs.spec
  WARNING: Bad pre-release versioning scheme!
  testcvs.spec
  -0.20080101cvs
  +0.20080101cvs.1

where the current patterns don't match fully. There's room for improvement
with very strict regexp that never bump any left number unless it is fully
compliant with the Fedora guidelines.

Very special cases like the following are not recognised at all:

  rc9.1%{?dist}

One could bump at the very right pos then, too.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]