Manjaro Linux (Arch derivative) installing obsolete 0.17 ?

[Kunda1]

The Arch AUR is downloading the FC 0.17 tarball from the 0.17 GitHub release page (seen here: https://aur.archlinux.org/cgit/aur.git/ ... reecad#n24 ) the odd thing is that once the package builds, it is showing is
Version: 0.17.5235 (Git shallow)
as seen below:

OS: "Manjaro Linux"
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.17.5235 (Git shallow)
Build type: Release
Branch: master
Hash: 3e6b68c0a1422860ec47160ff5c6b46ff8322a97
Python version: 2.7.14
Qt version: 4.8.7
Coin version: 3.1.3
OCC version: 7.2.0
Locale: English/UnitedStates (en_US)

Any ideas why ?

[sgrogan]

Version: 0.17.5235 (Git shallow)

Any ideas why ?

I think git shallow causes the "referencerevision" from here to be used: https://github.com/FreeCAD/FreeCAD/blob ... ev.py#L186

[Kunda1]

Version: 0.17.5235 (Git shallow)

Any ideas why ?

I think git shallow causes the "referencerevision" from here to be used: https://github.com/FreeCAD/FreeCAD/blob ... ev.py#L186

Yes and this confuses me. Is this hardcoded and incorrect?
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?

[sgrogan]

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.

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.

[Kunda1]

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.

So essentially this is in the hands of the distro packager to correct this, am I right? Should we then instruct packagers to do this just as you mentioned:

On the PPA we "merge" this [version.h file] into the source code.

Edit: shall I open a ticket on the tracker ?

[sgrogan]

So essentially this is in the hands of the distro packager to correct this, am I right? Should we then instruct packagers to do this just as you mentioned:

"essentially" yes, but...
It depends on the build system.
If git is available and the git history is preserved as part of the build process, CMake will handle it.
If the git history is discarded as part of the build process, it becomes more problematic.

For example, on the PPA(Lauchpad)
A source tarball is created automatically from the source git repo. We use some methods to merge a manually generated version.h into the tarball.
In the past NormandC did this locally as part of building the source tarball.

If the internet is available during the build process (it's not on LP), it's possible to use the GitHub web API to determine the version.

Edit: shall I open a ticket on the tracker ?

It's not a bug IMHO, as everything works as intended.

It's more of a feature request to change FreeCAD's visioning schema. I think some tickets already exist.
I think it's an artifact of being a beta project?
Major.Minor.Patch

We use commit count for Patch. It is more human understandable than the commit hash (which would have the same git build system problems)

[NormandC]

In the past NormandC did this locally as part of building the source tarball.

Specifically, I did that for official releases only. There's a script in FreeCAD sources to generate a tarball with Version.h info, but you need to config cmake first.

I wonder how Kurt tackled this for his Debian package of FreeCAD. It is certainly a pain for distro packagers.

[Kunda1]

In the past NormandC did this locally as part of building the source tarball.

Specifically, I did that for official releases only. There's a script in FreeCAD sources to generate a tarball with Version.h info, but you need to config cmake first.

I wonder how Kurt tackled this for his Debian package of FreeCAD. It is certainly a pain for distro packagers.

ping

@kkremitzki care to weigh in, buddy?