28.09.2013 13:16, Simon McVittie пишет: > On 28/09/13 08:59, Anton Balashov wrote: >> 28.09.2013 06:25, David Bate пишет: >>> I forgot to mention that the recommended git commit for Xonotic >>> 0.7.0 >> is 100eaf9137008 >> >> What version package will have if it will be based on some commit, >> i. e. not on a release tag? > > Here are the constraints on the package version: > > - must increase over time, even if you have to do another snapshot > before the next official release > - should be greater than the previous official release number > - should be less than the next official release number > - it's helpful for it to include an abbreviated git sha1 > > If there's a git tag at the last upstream release, you can use `git > describe` to describe a commit like this (using d0_blind_id as my > example upstream project): > > % git describe > v0.5-6-g86ae1d4 > > That means "6 commits later than the tag v0.5, and it's git commit > 86ae1d4". If I packaged that version of d0_blind_id, I'd probably > claim it was upstream version 0.5+6+g86ae1d4. > > Using the date instead of the number of commits also works, although > you can end up with pretty long version numbers (e.g. see ioquake3). > > S > > > v0.5-6-g86ae1d4 > > That means "6 commits later than the tag v0.5, and it's git commit > 86ae1d4". If I packaged that version of d0_blind_id, I'd probably > claim it was upstream version 0.5+6+g86ae1d4. We can't base on tags in our git repo, isn't? 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? And one more: What if there will be more than one deb pkg release based on the same commit? 0.3-42-dbca4321-1 and 0.3-42-dbca4321-2 ? I think base on date will be no good, because upstream author makes many commits in one day. What is the best practice? Thanks. Anton.
Attachment:
signature.asc
Description: OpenPGP digital signature