On Sun, May 19, 2013 at 06:07:07AM -0400, Alon Bar-Lev wrote:
> I believe git magic should not be used in source[1]

I don't see how git describe is unsuitable for this. From the examples
section of the manpage[1]:

<<<EOF

With something like git.git current tree, I get:

[torvalds@g5 git]$ git describe parent
v1.0.4-14-g2414721

i.e. the current head of my "parent" branch is based on v1.0.4, but since it
has a few commits on top of that, describe has added the number of additional
commits ("14") and an abbreviated object name for the commit itself ("2414721")
at the end.

The number of additional commits is the number of commits which would be
displayed by "git log v1.0.4..parent". The hash suffix is "-g" + 7-char
abbreviation for the tip commit of parent (which was
2414721b194453f058079d897d13c4e377f92dc6). The "g" prefix stands for "git" and
is used to allow describing the version of a software depending on the SCM the
software is managed with. This is useful in an environment where people may use
different SCMs.

Doing a git describe on a tag-name will just show the tag name:

[torvalds@g5 git]$ git describe v1.0.4
v1.0.4

EOF

Using this I think you can get consistent nightly build versioning. The
only downside I see is that you have to put the number of commits + hash
in the release so you can't bump when you change the spec file. This
isn't a problem since the spec file is included in git so any change
will be a commit, thus increasing the release anyway. Since the git hash
is included in the version it should make it even easier to exactly know
which version is being used.

[1]: https://www.kernel.org/pub/software/scm/git/docs/git-describe.html
_______________________________________________
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel

Reply via email to