On Wed, Aug 17, 2016 at 09:25:21PM +0200, Adam Borowski wrote: > > > > > If the repository contains any tags, I'd strongly recommend the output of > > > > > "git describe --tags". This will, beside DTRT when you're exactly on a > > > > > tag (ie, on a release), produce version numbers of the form: > > > > > <recent tag>-<# of commits>-g<short hash>, which is both monotonic if you > > > > > fast-forward and can be given to git to unambigously refer to the commit > > > > > you're uploading even to users of other branches. > > > > > > > > > > For example, one of my projects is currently at 0.17-128-g8606a54. > > > > This also will cause the package version to have nothing in common with > > > > the actual software version. I doubt we want this. > > > > > > Eh? How can you have _more_ in common with the actual version than "from > > > release X, add Y commits, of all branch tips Y commits later pick the one > > > whose hash starts with Z"? > > You are using a tag for an older software release so while the software is > > actually version 3.0 the package will have 2.0 version. > > Only if 3.0 hasn't been released yet, and there were no rc tags. In which > case, the version number will be 2.0-<big number>-g<hash>. If 3.0 hasn't been released yet, and the 2.0 tag exists, this has no place in this thread. -- WBR, wRAR
Attachment:
signature.asc
Description: PGP signature