+1kkremitzki wrote: ↑Fri Apr 12, 2019 3:15 pmThe problem with an evergreen 0.18 tag is that it becomes very difficult or impossible to troubleshoot issues by comparing different releases.
OK, therefor some would like to have point releases provided as a separate releases/tags. For i guess the purpose of easier obtaining the source code and changelogs. This is therefore sensible thing to provide. What is in my opinion not a sensible thing to do is to have binaries provided for all point releases. It's confusing and a huge maintenance burden.
Maybe if an orphan branch would be created and a single commit would be added. Some text describing that this isn't FreeCAD source code. That could i guess get tagged as "continuous" and maybe one more for "release". Here is where we would maintain development and latest (point) release binaries. Before each new release, we would archive the latest (point) release binaries, and the description text, from "release" to an appropriate release. From time to time i guess we would need to delete and recreate them, to bump them back to the top. That is, if such approach will end up working in the first place.I need to do some experiments on my github page.
For now i was thinking more in the direction of leveraging Conda based Windows builds. In addition to Linux and macOS ones. As for building directly on Travis. It's possible, but i don't know when that will happen.I still copy some stuff manually, but it could be scripted. We could also use the new libpack. @saso has done some experiments with this on AppVeyor. I think we can make it work, first step is to build Win on Travis. After that we can work on deploying it.
Today i went ahead and pushed some changes to AppImage repo. One remaining thing that i couldn't sort out just yet is to achieve successful deployment of Linux and macOS builds. Some sort of malformed url issue is at play, will try to figure out that part tomorrow.Thanks for the continued interest. We've come far in the last few years.
That part therefore got sorted out. But the result is not suitable for dealing with binaries. For that hopefully a more optimal solution will be the outcome of such discussions.kkremitzki wrote: ↑Fri Apr 12, 2019 3:15 pmThe problem with an evergreen 0.18 tag is that it becomes very difficult or impossible to troubleshoot issues by comparing different releases.
@probono's script offered the hint. Deploy "releases" to
This will always point to the latest release. Only caveat is that the release must exist. So when we create a point release (or regular release) tag, also create a release on the release page. 0.19_pre is a pre-release so it's separate.
triplus wrote: ↑Sat Apr 13, 2019 7:47 pmIt would be great if you could create FreeCAD 0.18.1 build with correct version information. Currently it isn't set correctly and the version script creates some garbled name. As a temporary workaround i have set the name manually. Testing AppImages i noticed 2 additional issues. QT Assistant path (try accessing help by pressing F1 key) is currently not set correctly and likely you removed too much libraries, as my system provided version of libstdc++.so.6 isn't compatible with bundled tibtbb.so.2 (0.18_pre AppImages didn't have such issue).
Yes it's maybe nice to have this for windows too, but first we have to solve the issues for linux and macos. All currently reported issues on linux seem to be related to hard-coded paths. These problems do not occur for freecad installed directly with conda-package-manager. If necessary we can switch the release back to the old toolchain which didn't had much issues with hard-coded paths.
Code: Select all
export QT_STYLE_OVERRIDE=gtk2