https://bugzilla.redhat.com/show_bug.cgi?id=1324590 --- Comment #28 from Michal Schmidt <mschmidt@xxxxxxxxxx> --- (In reply to paul.j.reger from comment #27) > To be clear, 10.1, is actually, currently in a pre-release state. I see. In that case Release value should be something like: 0.1.20160420git.%{?dist} as in the guidelines for pre-release packages: https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Pre-Release_packages > Still, I can make the initial value for the Release: tag as 1. The Release should be >= "1" only if an actually released Version or a later post-release snapshot is being packaged. > > From my previous comments it can be deduced that it cannot be valid for > > "%{release}" to appear in the Source URL of a Fedora package. > > Why? Because you won't the only person increasing the Release field in the Fedora spec. Suppose Fedora release engineering do a mass rebuild of all packages. They bump the Release of the package and kick off a rebuild in Koji. If "%{release}" appears in the Source tag, the URL just became invalid. > > In your role as an upstream developer, why don't you make a properly > > versioned tarball your primary deliverable? [...] > I do not believe that would work for our internal needs. We essentially > have a continuous integration testing scheme where every change in our > entire product creates a new product from probably millions of lines of > code. Hundreds of these CI builds are created, and are comprised of lots of > packages all consisting of 10.1 version, Continuous integration is good. > but also qualified with a unique release number. Does the release number of the package in Fedora have to be tied to the release number of packages you generate internally for your CI? -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component _______________________________________________ package-review mailing list package-review@xxxxxxxxxxxxxxxxxxxxxxx http://lists.fedoraproject.org/admin/lists/package-review@xxxxxxxxxxxxxxxxxxxxxxx