[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Versions based on custom commits

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.


Attachment: signature.asc
Description: OpenPGP digital signature

Reply to: