On Wed, 2012-06-13 at 13:22 -0700, Adam Williamson wrote: > On Wed, 2012-06-13 at 20:10 +0200, Pierre-Yves Chibon wrote: > > On Wed, 2012-06-13 at 11:45 -0600, Pete Zaitcev wrote: > > > On Mon, 23 Apr 2012 14:08:05 -0600 > > > Orion Poplawski <orion@xxxxxxxxxxxxx> wrote: > > > > > > > %global commit bd245c9 > > > > > > > > Source0: > > > > > > > https://github.com/jukka/pcfi/tarball/%{commit}/jukka-pcfi-%{commit}.tar.gz > > > > > > > > %setup -q -n jukka-pcfi-%{commit} > > > > > > I do not understand how this is supposed to work in the face of > > > "yum update". > > > > But if you read his email carefully, Orion isn't speaking about the > > version. > > So commit will be bd245c9 but the version might very well be > > > > Version: 20120613git%{commit} > > > > and as long as the date gets updated, yum will be happy with it. > > The guidelines actually require an integer before the date/rcs rev part, > which should be incremented at every build. Like so: > > 1.20110102git9e88d7e > 2.20110102git9e88d7e > 3.20120201git8fg34f6 > 4.20120201git8fg34f6 > > It doesn't get reset when you bump the snapshot, to double-plus-ensure > that no mess in the snapshot bit of the tag can ever cause problems. Erf. I forgot that if it's a pre-release snapshot, you make it %{version}-0.X.%{snapshot} . The rules are a bit complex :) but all make sense, and if you follow them, you should never get in trouble with updates not superseding. You should _always_ include a version, even if it has to be notional, and if it's notional, do everything you can to make sure it's lower than any possible version number upstream might actually release in future. Always include X (post-release) or 0.X (pre-release, so that the first actual release build can always be 1) before the snapshot bit, whatever snapshot naming format you're using. There are some good examples given on the page right under 'Pre-Release packages', it's worth looking at those. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
