Re: Doubts in Sigar packaging
On Wed, Sep 15, 2010 at 01:31:39PM +0100, Tony Houghton wrote:
> Matthew Palmer <firstname.lastname@example.org> wrote:
> > > sigar-1.7.0~git833ca18ecfc1f3f45eaf8544d8cdafef6603772d
> > Yeah, that isn't going to work -- what if the next SHA you want to
> > package is 12345[blah]... it'll look like a lesser version to dpkg.
> I had a similar problem when I moved roxterm to git . I only use
> git-derived versions for testing between releases but it's still useful.
> Here's a bit of script that can help:
> Date=`git log --date=iso | grep -m1 '^Date:' | sed 's/^Date:\s*//'`
> Rev=`date -d "$Date" -u +'%Y%m%d%H%M%S'`
Why won't you just use `git --describe`?
It produces nice version numbers of the format
<last tag>-<number of commits after it>-<start of hash>
(or just <last tag> when you're packaging a release)
The "start of hash" is a way to disambiguate in the case of multiple
branches based on the same release that happen to have the same number
of commits past that it; it will be the minimal repo-wide unambiguous
hash not shorter than (by default) 7 characters.
Unlike homebrewed versioning schemes, this one can be understood by git
without changes, no matter if you say 0.8.0-a0-1247-gf38ef2b, f38ef2b
Depending on your upstream's versioning scheme you may want to stick a
tilde somewhere. For example, if the upstream tagged a branch that is
to-be 0.8 as "0.8.0-a0", you'd want to make that "0.8.0~a0". This way,
"0.8.0-a0-1247-gf38ef2b" will become "0.8.0~a0-1247-gf38ef2b" and final
"0.8" -- just "0.8.0".
I recommend against using dates to mark revisions, since there probably
will be multiple commits in a single day, so there is no way to tell
which exactly version you did package.
1KB // Microsoft corollary to Hanlon's razor:
// Never attribute to stupidity what can be
// adequately explained by malice.