FreeCAD Forum

Since we're in October now and there is a lot of ground to cover before the end of the year, I thought it would be a good idea to start a thread about prepping for the next release. What needs to be done? when will there be a feature freeze announced? a documentation period, translation period...etc..etc..

Kunda1 wrote: ↑Tue Oct 08, 2019 3:02 pm Since we're in October now and there is a lot of ground to cover before the end of the year, I thought it would be a good idea to start a thread about prepping for the next release. What needs to be done? when will there be a feature freeze announced? a documentation period, translation period...etc..etc..

The next release won't come any time soon. Maybe we can think about it March/April/May 2020.

With all the recent big merges there have been many slight or big regressions here and there and also the general code quality has suffered greatly which the PVS and Coverity scans clearly show.

wmayer wrote: ↑Tue Oct 08, 2019 3:21 pm The next release won't come any time soon. Maybe we can think about it March/April/May 2020.

I think that was more or less the intended schedule anyway.

With all the recent big merges there have been many slight or big regressions here and there and also the general code quality has suffered greatly which the PVS and Coverity scans clearly show.

Does this affect mostly the C++ code? It seems to me you accepted the Link merge, but you are also not very happy with the way many things were implemented (tons of macros), so I guess some cleanup and refactoring needs to be done. Do the Python workbenches need to do anything in particular to help with this?

Does this affect mostly the C++ code?

Yes. The Python gurus like Bernd use some tools to improve the Python code and I don't worry at all about its quality.

It seems to me you accepted the Link merge

Yes. It was realthunder's third attempt to get the code merged and I didn't want to delay this further. I made a list of issues I have discovered so far and many of them are already fixed.

but you are also not very happy with the way many things were implemented (tons of macros),

Absolutely! I was never a friend of macros and considered them as necessary evil where they make really sense. But with the merge macros have been added throughout the code base and I am not happy with this step. I stumbled across several places where macros made the code really unreadable and it took me several minutes to understand it. IMO such code is almost unmaintainable because whenever something must be changed it can easily happen that you break something.

so I guess some cleanup and refactoring needs to be done

ezzieyguywuf made some PRs concerning some code refactoring and soon I will have a look at it, now that all pending PRs of realthunder are merged.

Do the Python workbenches need to do anything in particular to help with this?

I think they are OK.

I'd guess it's about time to consider the release timing of 0.19.

Are there any major features that are needed? My estimation of what's left for a 0.19 release from reading the forums is continued bugfixing after the Link merge.

For reference, the Debian Import Freeze for Ubuntu 20.04, the next long-term support release, is February 27th, so being done a fair bit in advance of that would be nice.

kkremitzki wrote: ↑Wed Nov 20, 2019 6:43 am...
For reference, the Debian Import Freeze for Ubuntu 20.04, the next long-term support release, is February 27th, so being done a fair bit in advance of that would be nice.

[Discussion] Preparing for the upcoming v0.19 release

wmayer wrote: ↑Tue Oct 08, 2019 3:21 pm The next release won't come any time soon. Maybe we can think about it March/April/May 2020.

With all the recent big merges there have been many slight or big regressions here and there and also the general code quality has suffered greatly which the PVS and Coverity scans clearly show.

Werner doesn't sound like he wants to rush things. However, I agree that it would make sense to include 0.19 in Ubuntu 20.04.

If 0.19 is included in 20.04, even with some issues, do you think we can still provide new versions 0.19.1, 0.19.2, etc., after the release, in April, July, etc., in order to correct outstanding issues that were not caught before the February deadline?

kkremitzki wrote: ↑Wed Nov 20, 2019 6:43 am

vocx wrote: ↑Wed Nov 20, 2019 7:12 am

Merged thread in to [Discussion] Preparing for the upcoming v0.19 release

kkremitzki wrote: ↑Wed Nov 20, 2019 6:43 am For reference, the Debian Import Freeze for Ubuntu 20.04, the next long-term support release, is February 27th, so being done a fair bit in advance of that would be nice.

I'm more comfortable with Werner's March/April/May estimate that I am with "well in advance of February 27".

Sounds like Werner and Yorik are tight for time for the rest of 2019, so that works again February too.

Kunda1 wrote: ↑Wed Nov 20, 2019 12:22 pm Merged thread in to [Discussion] Preparing for the upcoming v0.19 release

Aah, here is the thread. I was about to answer when suddenly the posts had vanished .

There is one serious topic we should at least have discussed before the release: Old models which are not extremely well built will rather probably break in 0.18. "Extremely well built" means that they have no references to edges, vertices or faces of solids.

The automatic numbering scheme has changed and I am sure there is good reason for that. To keep the code as clean as possible I would vote against special treatment of old models. Instead I see two possibilities:

1) Leave everything as is and keep 0.18 available for working on old models. Provide hints how to migrate manually.
2) Provide an extra migration program/workbench/macro - if possible after all - which lifts old models to 0.19.

Even solution 1) is well bearable as the step from 0.16 to 0.17 has proven. The actions to be taken now are much more straightforward.

chrisb wrote: ↑Wed Nov 20, 2019 3:42 pm There is one serious topic we should at least have discussed before the release: Old models which are not extremely well built will rather probably break in 0.18. "Extremely well built" means that they have no references to edges, vertices or faces of solids.

Why would they break? Also, do you mean models built with 0.18 will break in 0.19? Why? Please clarify.

The automatic numbering scheme has changed and I am sure there is good reason for that.

Automatic numbering of what? Faces, edges, body names? Please clarify.

...
Even solution 1) is well bearable as the step from 0.16 to 0.17 has proven. The actions to be taken now are much more straightforward.

Migration may not be automatic. Just because it was done before, it doesn't mean it will be easy now; it entirely depends on how the code is implemented. The LinkMerge introduced many big changes, so there may not be a direct migration path to follow.