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 <or...@cora.nwra.com> 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@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
