Release of 0.18

Here's the place for discussion related to coding in FreeCAD, C++ or Python. Design, interfaces and structures.
looo
Posts: 2655
Joined: Mon Nov 11, 2013 5:29 pm

Re: Release of 0.18

Postby looo » Fri Sep 28, 2018 8:32 am

kkremitzki wrote:
Fri Sep 28, 2018 6:45 am
So, that speaks for Debian, Ubuntu, and the PPAs. Can someone summarize the state of things with regards to the Python 3 release on Windows (traditional & Conda) and Mac?

conda-packages
Working conda-packages are available for FreeCAD/py3/qt5 (osx, linux64, win64) for quite some time. From time to time there is work needed to get things updated to the latest available dependencies (rolling release). I think freecad should be able to use the latest dependencies at the end of this week (freetype 2.9.1, tbb 2019.0).
Weekly freecad-builds are uploaded to freecad/label/dev. Releases will be uploaded directly to the conda-forge channel.

Main-Dependencies (for next freecad-build)
- occt 7.3
- python 3.6
- qt 5.6
- boost 1.67
- netgen 6.2.1808
- smesh 8.3.0.2 (not yet available)
- vtk 8.1.1
- pivy 6.4

conda-based portable windows packages
can't say much about this, as I haven't tested this yet and also I do not know the exact way how the bundles are created. For a release I think we should try to synchronize the dependencies of this build and the conda-forge-freecad-build.

conda-based appimages
Also here we should try to update to the latest dependencies and maybe also try to minimize the size of the bundle. Integrating my pip-tools would be a personal wish for a release, but I am not sure if this would be accepted yet.
smesh

py3 in general
In my eyes it's ready. But I do not use everything from FreeCAD. The real problem here is that developers still use py2. And why should users update to python3 before developers do. So we still have this chicken-egg problem (but it's getting better, and I guess everyone agrees that py3 is the future)
User avatar
sgrogan
Posts: 5201
Joined: Wed Oct 22, 2014 5:02 pm

Re: Release of 0.18

Postby sgrogan » Sat Sep 29, 2018 12:58 pm

looo wrote:
Fri Sep 28, 2018 8:32 am
conda-based portable windows packages
can't say much about this, as I haven't tested this yet and also I do not know the exact way how the bundles are created. For a release I think we should try to synchronize the dependencies of this build and the conda-forge-freecad-build.
For these I just strip the stuff from a conda env. I am working to get an x32 portable build to work. What's good is that these portable builds are suitable to build an installer from. I plan to use the standard release file naming for the installers packaged from this. For the older Libpack/VS2013 builds they will be PY2, I'll try to update to OCCT7.3 (OCCT7.2 presently). I don't have the bandwidth to update these to PY3/QT4. I will add legacy or to be deprecated or the like to the installer file naming to indicate the preference for the PY3/QT5 builds.

I don't update the conda env that I'm using for stability reasons, but I can create a new env to sync with latest conda before release. For a regular user this is transparent as I'm really just using conda as a Libpack. Big thanks to the Win testers in the https://forum.freecadweb.org/viewtopic.php?f=4&t=21405 thread :)
looo wrote:
Fri Sep 28, 2018 8:32 am
Integrating my pip-tools would be a personal wish for a release, but I am not sure if this would be accepted yet.
+1
Ideally we could have a custom directory, as to not mess with the users system installed python.
2nd choice would be to limit the use to pure python packages.
Either way, this would help to limit the package size. Now on the AppImages and Win builds we bundle some stuff that is useful or needed by 3rd party WB's to make it easy for the user. If we make this easy for the user we can only bundle this that are true core dependencies.
looo wrote:
Fri Sep 28, 2018 8:32 am
py3 in general
In my eyes it's ready. But I do not use everything from FreeCAD. The real problem here is that developers still use py2. And why should users update to python3 before developers do. So we still have this chicken-egg problem (but it's getting better, and I guess everyone agrees that py3 is the future)
To get the developers to use PY3 we have to provide the debug stuff to them.
For Debian based systems Kurt's work should accomplish this.
For Win, it will need to be conda based. My intention is to abandon maintenance of the VS2013 Libpacks after the 0.18 release, and start to pitch-in on conda debug packages, but I have A LOT to learn. @looo should have to do it all :oops:
User avatar
sgrogan
Posts: 5201
Joined: Wed Oct 22, 2014 5:02 pm

Re: Release of 0.18

Postby sgrogan » Sat Sep 29, 2018 1:02 pm

abdullah wrote:
Thu Sep 27, 2018 12:43 pm
To arrive happily with a good final release in February (Debian 10, see Kurt's post), a feature freeze should probably kick in early November at latest (and we are almost in October). The more we try to push in in the last minute, the longer testing and bug fixing will take, the longer translations will take, the longer updating the wiki will take. I think we do not want 2-3 months of "releasing". So, IMO there is about 1 month to go in the development cycle of v0.18.
+1
Very reasonable as always abdullah. I very much agree with this time line.
User avatar
bernd
Posts: 8019
Joined: Sun Sep 08, 2013 8:07 pm
Location: Zürich, Switzerland

Re: Release of 0.18

Postby bernd » Sun Sep 30, 2018 6:39 pm

sgrogan wrote:
Sat Sep 29, 2018 1:02 pm
abdullah wrote:
Thu Sep 27, 2018 12:43 pm
To arrive happily with a good final release in February (Debian 10, see Kurt's post), a feature freeze should probably kick in early November at latest (and we are almost in October). The more we try to push in in the last minute, the longer testing and bug fixing will take, the longer translations will take, the longer updating the wiki will take. I think we do not want 2-3 months of "releasing". So, IMO there is about 1 month to go in the development cycle of v0.18.
+1
Very reasonable as always abdullah. I very much agree with this time line.
+1 from me too.
looo
Posts: 2655
Joined: Mon Nov 11, 2013 5:29 pm

Re: Release of 0.18

Postby looo » Mon Oct 01, 2018 9:15 am

sgrogan wrote:
Sat Sep 29, 2018 12:58 pm
To get the developers to use PY3 we have to provide the debug stuff to them.
For Debian based systems Kurt's work should accomplish this.
For Win, it will need to be conda based. My intention is to abandon maintenance of the VS2013 Libpacks after the 0.18 release, and start to pitch-in on conda debug packages, but I have A LOT to learn. @looo should have to do it all :oops:
I think it's already possible to develop for py3. At least all developers which do mostly python work should be able to use release builds (path, arch, draft, ...)

Creating debug builds with conda should work. But thinking about providing a debug build of qt which is already nearly unmaintainable as a release makes me not want to do this job. So again I think it's best to wait for qt5.12 and help as much as possible with testing and porting qt-dependent packages. Later on we can maybe think about providing debug builds of qt5.12. So I don't think this will happen until june 2019. Trying to stay updated with deps feels already like a part-time-job...

Btw.: the tbb-problem which currently occured should be solved. FreeCAD and smesh conda-builds now directly depend on tbb-devel. I am not entirely happy with this solution, but at least it works. So the previously posted dependencies should work for appimages and win-builds.
User avatar
sgrogan
Posts: 5201
Joined: Wed Oct 22, 2014 5:02 pm

Re: Release of 0.18

Postby sgrogan » Thu Oct 25, 2018 10:23 pm

What would be a good date for a feature freeze?

"It's done when it's done", but I think we need a plan to "start getting ready, to get ready, to start"
triplus
Posts: 8415
Joined: Mon Dec 12, 2011 4:45 pm

Re: Release of 0.18

Postby triplus » Fri Oct 26, 2018 12:10 am

Based on my experience we are still far from having such detailed schedule. And likely we don't need it all that much ATM. As we i guess do what makes the most sense. Said that doing a release annually. In at least semi predictable time frame. That is end of the year (give or take a month). That is rather nice achievement already. ;)

P.S. There is still some time left. But closer we get to the end of the year. Less features should i guess be added.
User avatar
Joel_graff
Posts: 1355
Joined: Fri Apr 28, 2017 4:23 pm
Contact:

Re: Release of 0.18

Postby Joel_graff » Fri Oct 26, 2018 12:14 pm

Why not just set a consistent arbitrary feature freeze date - like three or four months before the final release?

If we want to consistently hit an annual release, a fixed feature freeze date guarantees the breathing room we need to prep for the release, even if there aren't a lot of outstanding bugs / instabilities to address.

In any case, if someone misses the feature freeze, it's not a big deal - there will be another guaranteed release in a year. And if a feature comes in late, but it's bug free and doesn't introduce any instabilities... or is just such a huge value-add that we have to add it, then we can. But really, a fixed, hard feature freeze gives us a window of time we can count on to catch our breath, reevaluate, and prep for the final release.

Anyway, there's no lack of non-feature work, as I see it - whether it's bug squashing, documentation, or more administrative matters (like writing a code of conduct, figuring out how to handle the money issue, developing a certification process, etc..). If a fixed feature freeze affords us more time to deal with other issues like that, then it's certainly worth it.

I suspect I may be overthinking things, though. :)
You can find the FreeCAD Trails workbench for transportation engineering on my github at:
https://www.github.com/joelgraff/freecad.trails
abdullah
Posts: 3174
Joined: Sun May 04, 2014 3:16 pm

Re: Release of 0.18

Postby abdullah » Fri Oct 26, 2018 1:39 pm

sgrogan wrote:
Thu Oct 25, 2018 10:23 pm
What would be a good date for a feature freeze?

"It's done when it's done", but I think we need a plan to "start getting ready, to get ready, to start"
This week it is about right :D

I am not following the big topics (like python3, qt5, ...). I think that what exactly to do depends on them. On their progress.

I think it is time for a new evaluation on the progress of these topics. Are they going to be ready soon? and relating to this: a) should we stick with our initial idea of including them in v0.18, or b) should be delay them to v0.19? I really hope for the former.

Other than those topics, I think that any moment is good to freeze development. Having another feature in v0.18 or not having it, it is just ok (even having many of the minor bugs solved in v0.18 or in v0.19 should not be a big deal). The only problem being that the "main" bugs that a new feature introduces, which should be reasonably debugged before release.

On the other hand, from a practical point of view it is not very interesting to stop the development of new features for a long period (one month would be ok, two months is probably too much, as it stops development).

So I think we should have an idea of when py3, qt5,... could be ready and define the feature freeze accordingly.
User avatar
yorik
Site Admin
Posts: 11371
Joined: Tue Feb 17, 2009 9:16 pm
Location: São Paulo, Brazil
Contact:

Re: Release of 0.18

Postby yorik » Fri Oct 26, 2018 2:33 pm

I still have one more "feature" to merge! (basically an improvement of the Arch Reference tool). But it should be done early next week.

The two people who know deeply about the current py3 and qt5 state are wmayer and looo. From my point of view, qt5 integration seems now basically complete, and I believe the missing components (qt5 webkit, etc) have now found their way into all main distros. We should check on Fedora and Ubuntu for pyside2, though.

For py3, it is already stable enough in the sense that it passes all the unit tests. There are still some encryption kinks here and there, though. And many external workbenches are still not ported.

I just switched my main build to be the py3/qt5 version, I'll try to do a more intensive use next week to kill as many remaining bugs as possible.