That's my opinion too, it seems to me that it is not *too* urgent to output a new version...jmaustpc wrote:But on Windows with those lib packs, perhaps it would be best to wait for the new OCC.
Release discussion 0.15
Forum rules
Be nice to others! Read the FreeCAD code of conduct!
Be nice to others! Read the FreeCAD code of conduct!
Re: Release discussion 0.15
Re: Release discussion 0.15
I agree as well, and while we're at it, I think it would make sense to publish soon(ish) a second bug fix release 0.14.37x for Windows, with the main goal being to update the libs so they are the same on the 32-Bit and 64-Bit versions, hopefully with OCC 6.7.1. The reason is this is a big source of confusion in the help area, we always have to ask users if they use 32 or 64-bit, recommend them to install the 64-Bit one if their OS supports it, tell them that their model has geometry problem but they can't see it because they only have OCC 6.6 or older...yorik wrote:That's my opinion too, it seems to me that it is not *too* urgent to output a new version...
32-Bit and 64-Bit Windows installers with identical libs and OCC 6.7.1 would really simplify things.
That is, once Peter completes his libpacks (but I do not want to put pressure on him).
Also, it would be nice to backport the fix for the working plane offset bug into the releases/FreeCAD-0-14 branch. Do you think it would be possible without too much work Yorik?
And apparently the FreeCAD 0.14.3702 package from the upcoming Ubuntu 14.10 repo has problems, so I'm going to have to upload one on the Stable Releases PPA, might as well be from the releases/FreeCAD-0-14 branch.
Re: Release discussion 0.15
Hm I'm not sure... I must locate the commit(s) that solve the bug and see if they can be applied cleanly to the 014 branchnormandc wrote:Also, it would be nice to backport the fix for the working plane offset bug into the releases/FreeCAD-0-14 branch. Do you think it would be possible without too much work Yorik?
Re: Release discussion 0.15
The OCCT 6.8.0 beta is out for two days. http://dev.opencascade.org/index.php?q=node/1003
And we are talking about upgrading the windows 32-bit libpack from 6.5.1 (2011-06) to 6.7.1 (2014-04)
And we are talking about upgrading the windows 32-bit libpack from 6.5.1 (2011-06) to 6.7.1 (2014-04)
Re: Release discussion 0.15
So do you think we should use OCCT instead of OCE on windows? I have never built it, so I don't know if it is more difficult to build or not. And would there be any advantage of using it?
How long can we wait until doing another windows build? I'm hoping to have my libpacks ready by the end of the week, but things usually take longer then I think they will.
How long can we wait until doing another windows build? I'm hoping to have my libpacks ready by the end of the week, but things usually take longer then I think they will.
Re: Release discussion 0.15
I'm sorry guys. Once Peter's automatic system is up and running, we can update libpacks weekly.
Re: Release discussion 0.15
I fully support the idea that there is no rush for a new final build. In my personal view if it comes somewhere in march or even june 2015 and one or two beta/unstable builds before that would seem totally ok. What I would however like to see is that there would be a time before the final release where the development of FC would be a bit more focused on testing and fixing bugs so that there would be a bit more confidence in the stability of the final release. Great things are happening, lets not get impatient and cut shortcuts
Regarding the Windows 32bit, as I remember Jürgens plan was to drop support for it? And about the 0.14 fix, can be, personally however I would focus on the future
Regarding the Windows 32bit, as I remember Jürgens plan was to drop support for it? And about the 0.14 fix, can be, personally however I would focus on the future
Re: Release discussion 0.15
I'm glad you amended your previous reply because I was pretty pissed this morning.shoogen wrote:I'm sorry guys. Once Peter's automatic system is up and running, we can update libpacks weekly.
Of course I was basing my opinion on the fact Peter was working on a system to automate libpack creation. I thought everyone here was aware of his project.
In this context updating the current stable releases to newer libpacks makes sense for the reasons I already mentioned. I would like to point out that OCC 6.7.1 is tried and tested on the Linux versions while OCCT 6.8.0 will be too fresh to base the 0.14 stable builds on. It will require testing. I will switch the Daily Builds PPA to 6.8.0 (or rather OCE 0.17?) as soon as it's available, but I think as saso mentioned there should probably be a few Windows development builds based on OCCT 6.8.0 before 0.15 is finally released with it.
And I believe it is a mistake. Like it or not computers running 32-Bit Windows are still plenty and shutting out all these users would not be good. I understand the reason behind Jürgen's intention, maintaining LibPacks has been up to now a huge job, which is why the current 32-bit Windows build is still based on an obsolete LibPack.saso wrote:Regarding the Windows 32bit, as I remember Jürgens plan was to drop support for it?
Re: Release discussion 0.15
I think I found it: git commit a7d1b80fyorik wrote:Hm I'm not sure... I must locate the commit(s) that solve the bug and see if they can be applied cleanly to the 014 branchnormandc wrote:Also, it would be nice to backport the fix for the working plane offset bug into the releases/FreeCAD-0-14 branch. Do you think it would be possible without too much work Yorik?
Re: Release discussion 0.15
Hi Normnormandc wrote:I think I found it: git commit a7d1b80fyorik wrote:Hm I'm not sure... I must locate the commit(s) that solve the bug and see if they can be applied cleanly to the 014 branchnormandc wrote:Also, it would be nice to backport the fix for the working plane offset bug into the releases/FreeCAD-0-14 branch. Do you think it would be possible without too much work Yorik?
I just tried this and it does indeed seem to fix the issue, in the version data shown below...which is FreeCAD compiled from the last bug fix commit in the 0.14 branch, i.e. a couple of commits or so, past the "release version".
For anyone wanting to know how I did this read on...
One of the advantages of the code being in Python is that you can test a change without needed to recompile your existing FreeCAD. So if you go into your compiled FreeCAD directory structure (not the source code) and open this file in a text editor /Mod/Draft/DraftTools.py then change the red high lighted line to the green ones shown in the commit which Norm linked to
https://github.com/FreeCAD/FreeCAD_sf_m ... t/a7d1b80f
You can then just start FreeCAD in the normal way and the bug is gone.
Jim
OS: Ubuntu 14.04.1 LTS
Word size: 64-bit
Version: 0.14.3705 (Git)
Branch: FreeCAD-0-14
Hash: f25e6e4716fb63ef3ac618ce9e552761bbc1b4b1
Python version: 2.7.6
Qt version: 4.8.6
Coin version: 4.0.0a
SoQt version: 1.6.0a
OCC version: 6.7.1