HISE Build Version should be changed incrementally

[DabDab]

As you can see I have used here HISE 3.0 where build time is the date when I compiled to source code to HISE binary. But build version is 650. In HISE 4.0 it is still 650. What is the meaning of it ?

It should be changed incrementally so that we get the idea what version of HISE we have compiled.
Every day HISE is rapidly getting evolved, packed with lots of new features. It will be a good practice to keep track of HISE build version.

[d.healey]

@DabDab I think the version and build number should be entirely abandoned and the git commit number should be used instead.

[aaronventure]

@d-healey I agree, if the directory is a git repo, it should automatically use the commit SHA instead of any number.

How do you handle it for cases where someone manually downloads the git repo? As far as I'm aware, the SHA isn't embedded anywhere. Is it just a hash of the entire repo?

[d.healey]

@aaronventure said in HISE Build Version should be changed incrementally:

How do you handle it for cases where someone manually downloads the git repo

Those people don't need to know :)

[Christoph Hart]

I think the version and build number should be entirely abandoned and the git commit number should be used instead.

Good idea. I've redesigned the about page to also include the most important preprocessor flags so you can see exactly how the current HISE version is built and with this I've also added a git commit SHA as an identification of the exact build state and if you click on the button it will take you to the exact git commit in the web browser.

There's a bit of black magic fuckery involved to get this to work:

• before every commit I'll run a short batch file that fetches the current git SHA of the repo and write it to 2 locations (one plain text file and one C++ header file that will be included the next time you build HISE.
• that commit will always be one behind the actual state, so when I'm loading that dialog, I'll call GitHub's API, fetch the list of commits to search the SHA, then pick the next commit as the one that matches the build state.

Another nice benefit of this system is that I can now compare the SHA of the HISE build with the SHA of the HISE source code at export and print a warning if there is a mismatch (a build mismatch between source code and HISE build is one of the more annoying issues as there are many things that can go wrong). I haven't implemented this check yet, but tomorrows another day.

[ustk]

@Christoph-Hart said in HISE Build Version should be changed incrementally:

Another nice benefit of this system is that I can now compare the SHA of the HISE build with the SHA of the HISE source code at export and print a warning if there is a mismatch...

Oh nice! I often get caught by this mistake since I am often running two versions of Hise simultaneously!

[d.healey]

@Christoph-Hart Can the git commit also be included in a snippet somehow? So when people post a snippet, asking for help, we don't have to keep asking which version of HISE they are using?

[Christoph Hart]

@d-healey good idea. Obviously we cannot disallow loading snippets with a hash mismatch but I can print a warning to the console.

[d.healey]

@Christoph-Hart Yeah, print snippet created with x commit or something similar. That way when we're trying to help people we can know what they're using.