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

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).


Reply to: