On Wed, 2011-09-21 at 09:55 -0400, Chris Lalancette wrote:
On 09/21/11 - 08:25:14AM, James Laska wrote:
> On Tue, 2011-09-20 at 16:53 -0400, Chris Lalancette wrote:
> > On 09/20/11 - 02:22:01PM, James Laska wrote:
> > > On Tue, 2011-09-20 at 13:19 -0500, Steve Loranz wrote:
> > > > The reason I use the git describe output is that it will use the last
tag and tell me how far away I am from it while still allowing me to get back to a
specific commit. That allows for meaningful version information like 0.6.1 to come from
the tag instead of having to manually edit the spec AND tag the source and hope that I
remember to do that each time we want to cut a release.
> > >
> > > Thanks for the explanation.
> > >
> > > > I'm not entirely clear on the utility of the timestamp portion of
the package name.
> > >
> > > I believe it's needed to ensure that a package built from git today,
is
> > > *always* newer than a package built from git yesterday. Since the
> > > git-hash isn't sequential, it's possible that RPM will interpret
an
> > > older git-hash as a newer/higher %{release}. To that end, I guess
> > > really only the date stamp is needed. However, I do appreciate having
> > > the short git-hash included since that clearly ties back to a point in
> > > git-history.
> >
> > Yep, exactly. When we originally came up with this scheme years ago, we
> > started out with githash only, as that is useful information when doing
> > debugging. We quickly ran into the situation that jlaska describes. So we
> > added the timestamp so that it would always be newer, and kept the git hash.
> >
> > I find the timestamp also useful on occasion, since you can pipe that into
> > date and find out when a package was built (and hence how ancient it is :).
>
> Is it worth considering adopting the timestamp+git-hash for other
> components (i.e. oz, imagefactory, iwhd, audrey, libdeltacloud)?
>
> I'm happy to craft up patches for the changes (assuming the changes are
> Makefile/spec file ... anything Rakefile I'll need help with). Before
> doing that, I was hoping to reach some consensus among the different
> component owners.
I'd be happy to accept a patch for that for Oz. libdeltacloud is no longer a
concern, as I pushed the patches to remove condor today. You'll have to get
buy-in from sloranz/imcleod for imagefactory, from meyering/zaitcev for iwhd,
and from blomquis/JoeV for audrey.
Thanks for the contacts. I'll follow up with each of them.
>
> Additionally, I imagine we want this %{release} format only for
> non-tagged git-built packages. For official tagged releases, I presume
> a standard numbered %{release} is desired?
Yes, that is exactly right. The "from git" builds are
<version>-0.<date>git<githash>, while the official release builds are
<version+1>-1
How do you make the distinction now for aeolus-{conductor,configure}
builds? Is a different make target used?
$ make rpms # official rpm build
$ make test-rpms ? # interim rpm development build?
Thanks,
James