On 09/21/11 - 10:02:36AM, James Laska wrote:
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?
We use a little trickery in the Makefile:
# For Release: 0..., set _conductor_dev=1 so that we get extra_release.GIT-
# annotated rpm version strings.
_conductor_dev = $(shell grep -q '^[[:space:]]*Release:[[:space:]]*0' \
aeolus-conductor.spec.in && echo 1 || :)
That is, if Release.startswith('0') in the spec, then we add the timestamp
and git hash, we don't otherwise. I think it's a manual process to update
the spec file, but I'll admit I haven't done a release in almost a year.
--
Chris Lalancette