[Ovirt-devel] [PATCH] A few specfile tweaks

[Daniel P. Berrange]

On Fri, May 02, 2008 at 10:40:50AM -0400, Hugh O. Brock wrote:
> On Fri, May 02, 2008 at 03:31:44PM +0100, Daniel P. Berrange wrote:
> > On Fri, May 02, 2008 at 10:19:24AM -0400, Chris Lalancette wrote:
> > It is important to distinguish the dev snapshots from the previous stable
> > release by version number. Merely bumping the release during development
> > does not really achieve this.
> > 
> > IMHO the way to deal with this is to
> > 
> >   - Immediately after a release:
> >       - Bump the version number
> >       - Reset the release number to '0.git1'
> >   - When making changes
> >       - Bump the last digit in the release number, eg '0.git2', '0.git3'
> >   - At time of release
> >       - Bump the release to '1'
> > 
> > This ensures that the RPM has a newer version number to indicate it is
> > functionality different from the previous stable release, and using the
> > leading '0' in Release: is following Fedora guidlines for pre-release
> > software release numbering scheme.
> 
> Yes, this is what I was thinking as well... does that imply
> incrementing the release number on every commit, though? And if so is
> it easier to use e.g. a changeset number in the release number to
> avoid having to manually increment the release number?

There is no linear increasing changeset number you can use with GIT really.

It is probably best to have the release number set at time of build rather
than manually changed by commits. eg, when we add an automated build script
I'd recommend the following be used in the autobuild.sh script:

  if [ -n "$AUTOBUILD_COUNTER" ]; then
    EXTRA_RELEASE=".auto$AUTOBUILD_COUNTER"
  else
    NOW=`date +"%s"`
    EXTRA_RELEASE=".$USER$NOW"
  fi
  rpmbuild --define "extra_release $EXTRA_RELEASE" \
            -ta --clean foo.tar.gz

And in the specfile:

  %define _extra_release %{?dist:%{dist}}%{!?dist:%{?extra_release:%{extra_release}}}
  Release: 0%{_extra_release}

So if a developer wanted to build an RPM from the current checkout just
running 'autobuild.sh' would then 'do the right thing' and create a RPM
with a release field newer than any previous build. And if the automated
build runs, it'll get tagged with the build counter

Dan.
-- 
|: Red Hat, Engineering, Boston   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|