#475 git hash & status in verison info #883
Conversation
(cherry picked from commit 94680ce5d5e4eaaa5cb8f970d458c0b53dbe0ea4)
|
We could also make your proposal compatible with the current one (just add git to the version). Or another proposal: 3.6.2 official release 3.6.2dev during development (unofficial)? This wouldn't break the changelog detection and be less confusing than 3.6.2git. |
That is a good idea. |
|
@fleutot and @storeilly Do you also like to comment on this pull request? |
|
I think that detailed version info needs to be available somewhere, especially for headless operation. |
|
@storeilly I think using "git describe [options]" alone suffices. It should look for the latest annotated tag and you wouldn't need to manually change "3.6.2". What do you think of the behavior of |
It's very clever and probably the correct method for the main code base, I'm not qualified to dispute it :) On my fork the hex string is enough for me. (Team of 1) |
Also I think a hash is "safer" for implementing, known length and uncritical characters: |
Jamulus.pro
Outdated
| } | ||
|
|
||
| #allow detailed version info for intermediate builds | ||
| contains(CONFIG, "official_release_version") { |
There was a problem hiding this comment.
Why to use a config flag for it? Couldn't you parse the VERSION and if you find a "dev" then you know it is a developer version and if no "dev" is present, you know it is an official release version.
There was a problem hiding this comment.
What I do when I create a new release is that I modify the ChangeLog and then I update the VERSION in the .pro file and create a Git commit from it. Then I apply the release tag. Then ann0see's automation detects that it is an official release version and starts his scripts. In that Git commit, the VERSION is set correctly to a release version number (which matches the entry in the ChangeLog).
There was a problem hiding this comment.
Then ann0see's automation detects that it is an official release version and starts his scripts [...]
Exactly. If you merge @nefarius2001 changes, the latest tag will not be applied to this commit and you'll still need to add it automatically. (Just wanted to add this).
There was a problem hiding this comment.
@corrados I had concerns, that somehow it might be forgotten/screwed up to add the "dev" appendix after removing it for the release. But it makes the job much easier, so lets go that road
There was a problem hiding this comment.
@ann0see "the latest tag will not be applied to this commit" -> What do you mean by this? Do you refer to your Git automation scripts which do a release if a release tag is applied to the repo? But here we are talking about the version number shown in the Jamulus software. If the "dev" is not there, nothing happens (at least when looking at the code after the latest change).
There was a problem hiding this comment.
I had concerns, that somehow it might be forgotten/screwed up to add the "dev" appendix after removing it for the release.
The is the very first thing I am doing after finishing a release. You can take a look at the Git history if you like.
There was a problem hiding this comment.
Do you refer to your Git automation scripts which do a release if a release tag is applied to the repo?
Yes. That was just an addition to your answer. I wasn't sure you were aware of this.
Everything else should be discussed between nefarius and you.
ef3aaf3 to
02abe23
Compare
|
Thanks. |
my answer to #475
for all "normal" builds a git hash will be appended, separated to the version with a "-"
by specifying "official_release_version" in CONFIG this is not happening
"3.6.2" << official release
"3.6.2-37f993aa" << intermediate release
"3.6.2-37f993aa-dirty" << intermediate release
tested on windows looking at the "about" info