On Wed, Sep 15, 2010 at 03:18:20PM +0200, Adam Borowski wrote: > On Wed, Sep 15, 2010 at 01:31:39PM +0100, Tony Houghton wrote: > > Matthew Palmer <mpal...@debian.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 [1]. 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.
You cannot use hashes in your version strings, because you can't assume that the "later" version is going to sort after the "earlier" version. If <tag>-<commitcount> isn't sufficiently unique, you're stuffed. Using a tag, however, is a possibility I hadn't considered. If you merge from upstream at relevant points and then tag in your repo, you could use 0.x.y~<tagname> as the upstream version. Again, README.source would need to document this convention, but you can control the content of the tag to make it monotonically increasing. > 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 > or f38ef2ba31de828e4b1961efe9b9e3cf91aadea6. For Debian packaging, this is irrelevant. > 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. If it is ambiguous, you can always put that sort of information in the Debian changelog, or perhaps README.source. - Matt -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100916052231.ge...@hezmatt.org