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

[Jim Meyering]

"Daniel P. Berrange" <berrange at redhat.com> wrote:
> 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?

Yeah, I hate having to do things like that manually.
If it's manual, it will eventually be done wrong.

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

Actually there is, if you arrange your development model a certain way,
and if you count change-sets in a centralized repository.
Run "git describe" in the ovirt repo.  Currently on master, it prints this:

  demo-2008-02-22-166-g7450ebc

That says we're on the 166'th change-set since the most recent
preceding (reachable) signed tag, "demo-2008-02-22".  Of course,
that doesn't help if you're interested in the 0.4 branch.
Hmm... even from the release-0.4 branch, there is no 0.4 tag.
Maybe the tip is it?  If the head of that branch is it, Chris
might want to tag it like this:

  git checkout release-0.4
  git tag -m 'oVirt 0.4' -s v0.4 HEAD

This mechanism to count change sets is most useful if you keep the
trunk "golden" (like git.git does) and do development on branches,
merging changes onto the trunk when they're sufficiently well tested.
Then most release tags are reachable from the head of "master".

For a project like git itself, since there's a v1.5.5.1 tag for that
release, git describe shows HEAD is 116 change-sets past that release:

  v1.5.5.1-116-ge4b9c36

It wouldn't take much to make this work for ovirt.
Just create a place-holder signed tag on master, e.g.,

  git tag -m 'oVirt 0.4.1 -- not a real release' -s v0.4.1 HEAD

and add infrastructure to propagate git change-set numbers to whatever
tools need it.

For example, with any snapshot build of coreutils,
I get a version string like this:

  $ cat --version|head -1
  cat (GNU coreutils) 6.11.43-d26e6
  [that's 43 change-sets past the 6.11 release tag]

For a release, it'd be the usual:

  $ cat --version|head -1
  cat (GNU coreutils) 6.11

If you're interested in the development model, a good summary of how
git.git does it (using three main branches, in addition to "master")
is described in http://members.cox.net/junkio/.