Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use "git describe" to display a nice rev-number #87

Closed
Ghabry opened this issue Feb 23, 2013 · 7 comments · Fixed by #2774
Closed

Use "git describe" to display a nice rev-number #87

Ghabry opened this issue Feb 23, 2013 · 7 comments · Fixed by #2774
Labels
Building Patch available UX For issues affecting the user experience, such annoyances, counter-intuitive or ugly design
Milestone

Comments

@Ghabry
Copy link
Member

Ghabry commented Feb 23, 2013

After creating our first tag (0.1) "git describe" can be used to get a more readable revision number 0.1-### (where ### is the number of commits since 0.1).

The output of "git describe" should be written in some header file and then be included by player and e.g. displayed in the title bar.

This makes it easier for us to figure out which version somebody uses (Maybe also write it in the PNG-tEXT chunk under "Software" if he used our screenshot function and we cant see the title bar). And to detect if somebody made local changes (e.g. by adding an 'M' after the rev number)

@Ghabry
Copy link
Member Author

Ghabry commented Mar 23, 2013

$ git describe
0.1-50-g56690ab
$ git describe | cut -d - -f -2
0.1-50

50 is the number of commits since tag 0.1

What do you think about adding some pre-compile step that writes this in a file for include?

@fdelapena
Copy link
Contributor

Well, hash tail is ugly but descriptive (makes easier to find the right tree here), but I have no preference though.

@Ghabry
Copy link
Member Author

Ghabry commented Apr 1, 2013

Ghabry@b11acb0

Feedback welcome (and updates to cmake + automake to invoke revision.sh)

@Ghabry
Copy link
Member Author

Ghabry commented Apr 2, 2013

"Looks legit, however in my opinion tagged (official) source packages, e.g. easyrpg-player-0.1-src.tar.gz should include pregenerated revision.h by default and not depend on git usage."

Ghabry@c212b17

Simple heuristic: Don't write file when .git is missing and revision.h exists.

@Ghabry
Copy link
Member Author

Ghabry commented May 21, 2014

@Lobomon
The build job sets now versionCode and versionName to proper values via some sed-magic:

versionName = git describe | cut -d - -f -2 | sed s/-/./g
versionCode = git rev-list HEAD --count

(this should become a part of the android build script later)

@fdelapena
Copy link
Contributor

For non-win32 ports, configure.ac and CMakeLists.txt has a builtin version number macro, doing a sed replacing for these on Jenkins jobs will generate a version define (autotools adds these defines to config.h). These can be patched before calling ./configure or cmake.

configure.ac and CMakeLists.txt standard define name for versioning is PACKAGE_VERSION
It can be assigned to the PLAYER_VERSION define or simply use it directly.

@Ghabry Ghabry modified the milestone: 0.5.0 Feb 19, 2016
carstene1ns added a commit to carstene1ns/easyrpg-player that referenced this issue Feb 28, 2016
carstene1ns added a commit to carstene1ns/easyrpg-player that referenced this issue Mar 1, 2016
fdelapena added a commit that referenced this issue Mar 4, 2016
@Ghabry Ghabry modified the milestones: 0.6.1, 0.6.2 Jul 14, 2019
@Ghabry Ghabry removed this from the 0.6.2 milestone Feb 17, 2020
@Ghabry
Copy link
Member Author

Ghabry commented Mar 23, 2022

Considering we are full CMake and Autotools now it should be finally possible to add this without toooo much afford?

See also #2070

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Building Patch available UX For issues affecting the user experience, such annoyances, counter-intuitive or ugly design
2 participants