Build number in Openbor

[msmalik681]

Damon Caskey

As you requested I have made a git hook that will record what should be the build number by recording the master branch commit count then adding the current branch's commits ahead of master so when merged you should get the correct build number matching the commit count on master after the merge.

There is a small window of error if two pull requests are made at the same time but as all pull requests have to be reviewed this can be address before merge and we can request a extra commit added to the branch before making another pull request.  Besides this small issue I believe this is much better then the current process of adding a build number into openbor (current process we do not add a build number into source code).  If you are happy with this I will continue work to incorporate this to our github repository and instructions for developers to use this process.

my pre-commit hook:

#!/bin/sh
#pre-hook to log master commit count then add branch ahead of master and record into a build_number.h file.
countM=$(git rev-list master --count) #master commit count
countB=$(($(git rev-list master.. --count) + 2)) #branch ahead of master commit count +1 for the merge +1 for this commit.
echo $(($countM + $countB)) > build_number.h
git add build_number.h
exit 0

This will be updated to suite our engine.

 

[O Ilusionista]

So this will include the the build version when you compile the engine? If so, this is great.

 

[msmalik681]

Exactly this is something we have needed for a long time.

 

[O Ilusionista]

For sure we need it!
Thanks for your effort.

 

[msmalik681]

Damon Caskey waiting for a green light on this.

 

[DCurrent]

Sorry, I missed this. I don't really see a problem other than setting up hooks can marry you to Github, and I'm not a fan of that... else-wise go ahead.

DC

 

[msmalik681]

Looks like I have a wedding to get ready for  ;D

 

[msmalik681]

Wow this was more complicated then I thought it would be but I am almost done just need to confirm the build number is showing across platforms.

 

[O Ilusionista]

Nice work

 

[msmalik681]

Plombo Damon Caskey O Ilusionista haxpor

Calling all developers I have just made a pull request to add build numbers into OpenBOR once it has been approved could you follow these instructions please.

I have added a copy of my pre-commit to the folder "engine/source/" please copy that file to your local ".git/hooks/" directory then update your branches from master. When you commit to git hub using command prompt or github desktop you will find the file "engine/source/build_number.h" will update to match the master branch commit count + how many commits your branch is ahead of master +2 when your make a pull request it will perfectly match the master builds commit count after merge.  If your see someone has a pending pull request please hold yours until theirs is merged then make 1 extra commit to update the build number then make your pull request. Thank you for your time.

haxpor sorry I have broken compatibility with Linux again (see my updated build.bat for android) can you help please.

 

[DCurrent]

Uhm... that last part actually sounds pretty messy, and I don't like it at all. I want to hear other dev opinions first. If everyone is on board, I'll dismiss my concerns and approve it.

DC

 

[Plombo]

I have added a copy of my pre-commit to the folder "engine/source/" please copy that file to your local ".git/hooks/" directory then update your branches from master. When you commit to git hub using command prompt or github desktop you will find the file "engine/source/build_number.h" will update to match the master branch commit count + how many commits your branch is ahead of master +2 when your make a pull request it will perfectly match the master builds commit count after merge.  If your see someone has a pending pull request please hold yours until theirs is merged then make 1 extra commit to update the build number then make your pull request. Thank you for your time.

I'm with Damon here. This is super messy and I don't like it at all. Automated build numbers aren't worth all of that.

 

[msmalik681]

Ok so how about we manually update the build number before we compile for a release?

 

[haxpor]

Hey msmalik681 , I just pulled latest from upstream, and re-built on android, still works fine.

I give my humble opinion, I see the intention of this. What's about use commit hash to refer when discuss from point of view for devs, and from time to time when to make a new official release to users, then properly mark via tags (this is already did). Add on top, to support users that do a manual build pulling from arbitrary state of code base from github, use commit hash in discussion.

And from log, might be a good idea to spit commit hash into the log so whenever users sent in crash log for investigation, devs know specific commit to point to.

For reference and good example, aseprite (https://github.com/aseprite/aseprite) uses this approach and works quite well. It can pin-point stuff quickly both for author(s) itself and users. Also, it shows version string (beta, or released version, or arbitrary commit hash) inside the app.

Edit: I re-read my comment, and think about it more.  It's not quite right. It seems to retain information about build number / hash commit and let engine knows about it, seems no other method than pushing it into project's source code. Now it's just a matter of how to make it clean. If I have any more thought about this, I'll go back to this thread.

 

[O Ilusionista]

I'm with Damon here. This is super messy and I don't like it at all. Automated build numbers aren't worth all of that.

Can I give my humble opinion here?

I do not want to sound ungrateful or disrespectful, but having the build number is extremely necessary, because being able to identify which version of an engine we're using is so basic that the absence of it is quite embarrassing for the engine.

I think it's the first time I work with a program that I can not identify which version it is. Ok, there is a method, but having to access a site and be looking for (by release date) the version of the engine is through boring and embarrassing to. It is not something we have to give up and simply ignore.

 

[DCurrent]

We're not giving up, or ignoring. But the only thing worse than no automation is partial automation. The effort is appreciated, but the proposed method here is not workable in a development environment, full stop.

We're currently looking at other methods.

DC

 

[msmalik681]

I will look at adding a git hub in the tools section to pull the master commit count and add it to the release as all releases should be the latest master build.  So it will be messy if anyone compiles from a old source to have the latest commit  count on there so by default I will look at adding a debug text/number.

O Ilusionista I know how much we need this so don't worry it will be added soon.

Damon Caskey the whole tools folder has been added to gitignore I want to change this to ignore any extracted folders from building instead otherwise we can not update the tools.

 

[DCurrent]

Damon Caskey the whole tools folder has been added to gitignore I want to change this to ignore any extracted folders from building instead otherwise we can not update the tools.

Sure, go ahead. That was just a temporary solution anyway.

DC

 

[msmalik681]

Damon Caskey

I have pretty much re-submitted the same update with no hooks and some little extras.  I suggest we leave updating the build numbers to a manual process as part of the current manual release process we have.  We can change this when there is a better solution but for now it works and it only requires one small step in the build process.  By default the build number will be 0000 this can identify test and debug builds.

 

[haxpor]

msmalik681 thank you for continued effort! So in summary, for any new PR, what exactly we need to do? Thanks