9/28/13 4:40 PM, Simon McVittie пишет: > 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 > > Hi, Simon. I want to say: thank you for awesome description! :) That is deserving respect. I'll use git describe and "+". About base on date: I meant author makes many commits in one day - not I :) And end user wouldn't know from what exactly upstream source (commit) it was built. At least from the pkg name. Thanks. Anton.
Attachment:
signature.asc
Description: OpenPGP digital signature