Re: Versions based on custom commits
On 28/09/13 11:10, Anton Balashov wrote:
> We can't base on tags in our git repo, isn't?
I was referring to upstream releases/tags.
> Yes, we can use number of commit after release tag, but it can
> looks a little strange :) I mean 0.3-24-abcd1234 and a next version
> for example is 0.3-42-dbca4321. Is it ok?
OK, here's a more concrete example. Suppose the upstream author of
"mygame" has this git history on their "master" branch (as seen in
gitk or git log, so, newest first):
(commits since 0.3)
* dbca4321 fix crash, #66 5
* 520e0262 refactor another thing 4
* 532063a4 refactor a thing 3
* abcd1234 add a feature 2
* 602802ab fix bug #47 1
* 40106025 release 0.3 <[tagged "mygame-0.3"] 0
* aabbc462 fix bug #12
... etc
and suppose I packaged abcd1234, first, then updated to dbca4321 to
fix upstream bug 66.
"git describe abcd1234" would print "mygame-0.3-2-gabcd123" because
it's 2 commits later than the mygame-0.3 tag. I would version the
Debian package like this:
mygame (0.3+2+gabcd123-1) unstable; urgency=low
* New upstream git snapshot
Then, when I upgraded to commit dbca4321 (for which "git describe
dbca4321" would output "mygame-0.3-5-gdbca432", it might look like this:
mygame (0.3+5+gdbca432-1) unstable; urgency=medium
* New upstream git snapshot
- no longer crashes when you get the quad damage
(Closes: #123456)
(This is a bit of an artificial example: in real life, you'd hopefully
apply crash fixes as a Debian patch rather than updating to some
random snapshot, and you'd hopefully update to a new snapshot less
frequently than twice in 5 commits - but a more realistic number of
commits between snapshots would have taken a lot of space in this
email :-)
You could leave the "-" in the version instead of replacing them with
"+", but that makes it less obvious which bit is the Debian revision.
It's actually unambiguous in Policy and the tools - the revision is
the part after the *last* "-" - but it's less obvious to a human reader.
> And one more: What if there will be more than one deb pkg release
> based on the same commit?
It's just the same as if you base more than one Debian package on the
same upstream release: you increment the Debian revision (the part
after the last "-") instead of the upstream version.
So, continuing the example above, I might follow that upload with:
mygame (0.3+5+gdbca432-2) unstable; urgency=low
* debian/postrm: remove logfiles during purge (Closes: #654321)
> I think base on date will be no good, because upstream author makes
> many commits in one day.
If you upload more than one upstream snapshot from a single day's
development, you're probably uploading more often than you really need
to :-)
But yes, that's another disadvantage of using the date. You could
follow 0.3+git20130928 with 0.3+git20130928.1, or something, if you
really needed to (I made sure the versioning scheme for ioquake3
allows for this, although thankfully I've never needed it).
S
Reply to: