Bug 435927 - Release tag doesn't follow guidelines
Release tag doesn't follow guidelines
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: frysk (Show other bugs)
8
All Linux
low Severity low
: ---
: ---
Assigned To: Andrew Cagney
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-03-04 09:29 EST by Andrew Overholt
Modified: 2008-03-04 10:33 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-03-04 10:33:00 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
potential patch (1.00 KB, patch)
2008-03-04 09:29 EST, Andrew Overholt
no flags Details | Diff

  None (edit)
Description Andrew Overholt 2008-03-04 09:29:31 EST
The frysk RPM version and release strings don't comply with (my interpretation
of (?)) the naming guidelines:

0.0.1.2008.02.29.rh1-1

http://fedoraproject.org/wiki/Packaging/NamingGuidelines#PreReleasePackages

Assuming that version 0.0.1 is pending, this means that the frysk _version_
should be  "0.0.1" and the _release_ should be "0.x.YYYYMMDDgitZZZZ" (an
abbreviated git hash, < 13 'Z's).  In this case, we'd have:  version="0.0.1"
release="0.1.20080229git<whatever the hash is>".  If patches were made later to
this snapshot RPM, the 'x' component of the release would increment by 1 each
time.  The ".%{?dist}" may be tacked onto the end if you wish.  Further
snapshots would restart at 1 with the appropriate date and git hash:

0.0.1-0.1.20080229git<whatever the hash is> (existing package)
0.0.1-0.2.20080229git<whatever the hash is> (patch or something to existing)
0.0.1-0.1.20080324git<whatever the hash is> (new snapshot)
0.0.1-1 (actual 0.0.1 release)
0.0.1-2 (patch to 0.0.1 release)
...
1.0-1 (1.0 release)

*However*, because the existing version is incorrect, changing it to meet the
guidelines will result in all future RPMs being "older" in rpm parlance than the
existing one.  There are two ways to fix this:  1) add an epoch and 2) make the
version "0.0.2".  Choice #2 is much preferred, but I guess it sort of depends
upon whether or not upstream has released 0.0.1 yet ... or if the "next" (which
could be the first) release upstream will be 0.0.2.
Comment 1 Andrew Overholt 2008-03-04 09:29:31 EST
Created attachment 296739 [details]
potential patch
Comment 2 Andrew Cagney 2008-03-04 10:25:05 EST
The frysk tarball is:

   frysk-0.0.1.2008.02.29.rh1.tar.bz2

and the full version number branded into the executable is:

  $ ftrace --version
  0.0.1.2008.02.29.rh1

there's a balance here between fedora an its deals and frysk's realities.  The
current system is clearly not causing problems.

I trust we can see through to some sort of sane compromise.
Comment 3 Andrew Overholt 2008-03-04 10:33:00 EST
That's an interesting version number for the upstream tarball :)  If that's what
it is, that's what it is, though.

Note You need to log in before you can comment on or make changes to this bug.