Kunda1 wrote: ↑Wed Apr 18, 2018 10:42 am
As you mentioned in gitter this may also be due to a limitation of using GH as a release platform since once the release is tagged, the tarballs can't be changed. So if I'm understanding correctly these may be incorrect/obsolete versions of 0.17 release?
There are several things happening here. (using 0.17 release as an example)
First, when FreeCAD is released, a releases/FreeCAD-0-17 branch is created. From this branch a "release" is created. When created the release is tagged to the releases/FreeCAD-0-17 branch and named 0.17 by convention so we have a static target for the various CI/CD workflows that FreeCAD uses (Travis, AppVeyor, scripts etc.)
The source tarball assets are auto-deployed by the GitHub Releases API. Then the FreeCAD team uploads additional assets (ie the binaries).
Great now we have a release
Now some commits are backported to releases/FreeCAD-0-17
We can update the binary assets, this is becoming more automated all the time. But the source tarballs are not updated. So as of today the source tarballs are 0.17.13509, but the release assets are up to 0.17.13514.
We could create releases for every push to releases/FreeCAD-0-17, but the logic gets complicated because the release assets come from multiple sources. I tried this with the 0.16 backport release, it caused more confusion than it helped.
Kunda1 wrote: ↑Wed Apr 18, 2018 10:42 am
Yes and this confuses me. Is this hardcoded and incorrect?
Now, how FreeCAD determines it's version.
When running cmake FreeCAD checks for the presence of an version.h file at src/build. If it exists FreeCAD uses it to populate the "About FreeCAD". On the PPA we "merge" this into the source code.
If the version.h does not exist the script I linked above is run to create it.
The script first tries to identify the VCS. If it can't it reports the version as unknown.
Somehow, and I'm not sure why, your case identifies the VCS as Git.
Then the scripts tries to count the commits from the referencecommit to to determine the version relative to the referenceversion.
If the script can't find the reference commit, which in your case it can't because the tarball doesn't have the git history it reports Git shallow and sets the version to the referenceversion. I can't figure out where the HASH comes from.
