Back port commits to 0.18 branch

[triplus]

As for the version number. Travis will set the package (version) name, based on whatever FreeCAD says the version is. I feel that this approach makes the most sense. Hence @looo would need to patch FreeCAD package on Conda side, and use some arbitrary version number, like for example 0.18.4. Currently packagers are resulting to all sort of hacks, trying to achieve that, i find that messy. This probably needs to get addressed upstream. By for example explicitly committing such value, at some point, to the 0.18 branch, and in such case, for it to be used automatically, when compiling the FreeCAD.

Anyway osx is seeing brew-issues again. So this might need some time to be solved. (Last time we saw such errors it somehow got sorted by itself.)

Yes, such things usually sort themselves out, on Homebrew/Travis side. This time, due to the issue already persisting for around 10 days and due to point release just being made, i added a workaround, and macOS people can now join the party.

[looo]

As for the version number. Travis will set the package (version) name, based on whatever FreeCAD says the version is. I feel that this approach makes the most sense. Hence @looo would need to patch FreeCAD package on Conda side, and use some arbitrary version number, like for example 0.18.4. Currently packagers are resulting to all sort of hacks, trying to achieve that, i find that messy. This probably needs to get addressed upstream. By for example explicitly committing such value, at some point, to the 0.18 branch, and in such case, for it to be used automatically, when compiling the FreeCAD.

I see, so we are talking about the version set in the version.h file. I thought this was about the file-name of the appimage/dmg.
In this case, indeed this must be done before building the package. There are for sure ways to do this in the build-scripts by using the version of the conda-package which is available as an environment-variable.
As we use git there are also other alternatives, like using the latest tag and add the additional commits. But as git tags are not strictly increasing for FreeCAD (0.19_pre, 0.18.x, ..) this will not work out of the box. At least I got something like (freecad_link-merge_xxx-commits as package name, when I tried this approach.)

Yes, such things usually sort themselves out, on Homebrew/Travis side. This time, due to the issue already persisting for around 10 days and due to point release just being made, i added a workaround, and macOS people can now join the party.

Nice! Thanks.

[sgrogan]

Nice! Thanks.

+1
Moved packaging discussion here: https://forum.freecadweb.org/viewtopic.php?f=42&t=40614

[triplus]

I see, so we are talking about the version set in the version.h file. I thought this was about the file-name of the appimage/dmg.

Yes, this is the main problem. We started doing point releases, some people would like for that to be reflected in FreeCAD version name, currently hacks are being used, to achieve such results, when creating the packages. In addition some scripts out there do check for the version name, not yet taking point release version name scheme into consideration. For example replacing revision number 16146 with a number such as 4, that i guess can make a script, expecting a higher number, to assume, older FreeCAD version is being run.

Nice! Thanks.

You're welcome.

P.S. Just wondering, how hard would it be to create a Conda Linux FreeCAD 0.18.4 test package, containing this code changes:

https://github.com/FreeCAD/FreeCAD/blob ... istant.cpp

[looo]

P.S. Just wondering, how hard would it be to create a Conda Linux FreeCAD 0.18.4 test package, containing this code changes:

https://github.com/FreeCAD/FreeCAD/blob ... istant.cpp

added:
https://github.com/looooo/freecad-feeds ... 2718be5231

If it doesn't work we can move back to the origin 0.18.4 build.

[engdham]

Hello,

Not sure if this is the right place to talk about it, but the download link for the Windows version on the site is still pointing to version 0.18.3, although 0.18.4 is already available.

[triplus]

added:
https://github.com/looooo/freecad-feeds ... 2718be5231

If it doesn't work we can move back to the origin 0.18.4 build.

Great to see such patches can be applied in a rather straightforward fashion. I tested the FreeCAD 0.18.4 AppImage and unfortunately it still doesn't work. An additional quirk is involved somewhere, Qt Assistant doesn't want to unregistered the documentation and it doesn't provide a reason, on why it fails. Will do some more tests in the following days.

[bernd]

a reminder

git commit 7d96016
git commit f1a3a62
git commit 1f53e8b

[wmayer]

a reminder

git commit 7d96016
git commit f1a3a62
git commit 1f53e8b

Done!

[openBrain]

Maybe as 0.18 probably has to live for quite a time, integrating this git commit can prevent bad behavior in SVG import when users will tend to use new Inkscape versions.
Backporting this git commit about 'pt' unit definition at the same time can optionally be a good thing.