PartDesign Next

Here's the place for discussion related to coding in FreeCAD, C++ or Python. Design, interfaces and structures.
ickby
Posts: 2463
Joined: Wed Oct 05, 2011 7:36 am

PartDesign Next

Postby ickby » Sun Apr 10, 2016 7:32 am

Hello,

so the 0.16 release branch has been created, everything is good to go for 0.17 :) Now one huge question we need to answer is how to proceed with the PartDesign Next branch. It contains many many changes, most to PartDesign, but also quite a few to other workbenches like Part and the FreeCAD base code. Hence merging will be disruptive, it will change and most likely break things and it will take a while till everything will work again. But is has to happen at some point, as it is not only a hughe improvement in workflow but also the base for the assembly workbench. Here I see the following options

  1. Merge now and fix things in master
    1. Pro:
      1. Many testers, will help fixing bugs
      2. Other developers can use the new goodies like enhanced groups and coordinate systems
      3. Most likely more developer time spent on making the new stuff production ready
    2. Con:
      1. Development version would become rather unstable for a while
  2. Further develop in Branch
    1. Pro:
      1. 0.17 dev would stay stable
    2. Con:
      1. Development of PartDesign next would go rather slow as it is now
      2. System bugs outside of part design will most likely not be catched due to reduced testing
      3. Keeping the code in sync with master generates lot of work

So I'm cleary for option 1, merging it now. What do you other guys think about it? I may also have forgotten things, anything to add to the list?

Btw: I rebased the code to master yesterday, so it is in a good and healthy state right now :) https://github.com/blobfish/FreeCAD_sf_ ... baseMaster

Pul request for technical discussion: https://github.com/FreeCAD/FreeCAD/pull/135
Last edited by ickby on Sun Apr 10, 2016 4:57 pm, edited 1 time in total.
User avatar
f3nix
Posts: 213
Joined: Sat May 30, 2015 11:58 am

Re: PartDesign Next

Postby f3nix » Sun Apr 10, 2016 7:41 am

Hi,
option 1 for me please. :) Your points are totally valid!

Cheers,
Mateusz
DeepSOIC
Posts: 4693
Joined: Fri Aug 29, 2014 12:45 am
Location: Saint-Petersburg, Russia

Re: PartDesign Next

Postby DeepSOIC » Sun Apr 10, 2016 10:30 am

Option 1, please! :D
User avatar
JMG
Posts: 263
Joined: Wed Dec 25, 2013 9:32 am
Location: Spain
Contact:

Re: PartDesign Next

Postby JMG » Sun Apr 10, 2016 10:51 am

Option 1 for the win! :)
FreeCAD scripts, animations, experiments and more: http://linuxforanengineer.blogspot.com.es/
Open source CNC hot wire cutter project (NiCr): https://github.com/JMG1/NiCr
Exploded Assembly Workbench: https://github.com/JMG1/ExplodedAssembly
User avatar
saso
Posts: 624
Joined: Fri May 16, 2014 1:14 pm
Contact:

Re: PartDesign Next

Postby saso » Sun Apr 10, 2016 10:56 am

I was thinking about some similar things lately. My short answer to your question would be, just do it (option 1) :) the longer answer is however... well a bit longer, but still option 1 :)

Additionally to the bigger changes that PartDesign Next represents, I would like to bring to the topic also two other issues, first is just the fact that actually we have quite a few bigger changes in the pipeline, not just PartDesign Next. It would probably be good to make a list of them and rethink a bit if there needs to be an order how they get merged and develop further (make them stable). Few of the bigger ones in no special order: PartDesign Next, VTK, Python 3, Qt5, OCC7, new things in FEM wb, new Drawing wb,... ?

Second is the discussion there was about moving to an 0.17 development -> 0.18 release -> 0.19 development -> 0.20 -> release, type of cycle. Personally I would vote NOT to do that. From my experience this can be quite confusing for a lot of new and general users (who just use the program and don't follow the development), and for those who do follow the development it generally does not really make a difference. What I would however like to support in this matter is (since we have made the switch to GitHub and now have Travis) to make one more step in this direction and think about adopting a git branching model that is more similar to the one suggested here http://nvie.com/posts/a-successful-git-branching-model/ A simple upgrade from our current workflow would be to just add an "develop" branch and move our main development from master to it. Bruce has suggested this lately, I believe it was also suggested and discussed in the past by others and it does seem to make sense to me and it should help to address some of the issues that we were trying to improve with the above release cycle and also help with merging in all of the new stuff (but I am not a developer :oops: ).

To make the long answer short again... Adopt the new git branching model and then just do it, start to merge in all the new things as fast as possible, but have them stable enough for Travis builds and tests to be happy. About having a stable program to use, we can enjoy the new final 0.16 release for a while :)
Last edited by saso on Sun Apr 10, 2016 1:45 pm, edited 4 times in total.
User avatar
bejant
Posts: 4125
Joined: Thu Jul 11, 2013 3:06 pm

Re: PartDesign Next

Postby bejant » Sun Apr 10, 2016 12:37 pm

As a user I'd prefer option 1, although it might also be good to break tradition and offer the last 0.16 release as a standalone for Linux too.
My Part Design tutorials on YouTube (aimed at beginners).
triplus
Posts: 5000
Joined: Mon Dec 12, 2011 4:45 pm

Re: PartDesign Next

Postby triplus » Sun Apr 10, 2016 1:31 pm

I would vote for:

Create official fork of FreeCAD 0.16. This is what users should be instructed to use for production work. Try to do point releases with small bug fixes if they are worth fixing in 3 to 6 month cycle. Set fix date when point release will be released to test out how this works out.

Merge PartDesign Next, Python 3, PySide2, Qt 5 support and Qt 5 related projects on hold, TechDraw ... in master! Don't care for backward compatibility for now in areas where nobody is working on it. Therefore brake everything when doing this (as it will get broken anyway) and try to fix it later. ;)

This will be a huge challenge but if we don't do it it could happen in the next year we will be asking ourself the same question. Should we go forward or not. And if it wouldn't work out we can still go back after a year and put only the things that work in the FreeCAD 0.16 point release 2 (or 4) forked branch. ;)
jmaustpc
Posts: 8101
Joined: Tue Jul 26, 2011 6:28 am
Location: Australia

Re: PartDesign Next

Postby jmaustpc » Sun Apr 10, 2016 1:47 pm

Hi Stefan
ickby wrote:1. Merge now and fix things in master


I think merging into master as soon as possible is the best idea.

I think we should get the big "problems" and "instabilities" into master as soon as possible in a development cycle while instability is still expected, by the time a few months have gone by, most of us will be want to be using master regularly due to the inclusion of some new killer feature or other. So adding a big disruptive change is likely to be more of an inconvenience to advanced users the longer we wait.

I think failure to merge quickly is just too de-motivating to a lot of us. All of you who have worked on this deserve to have your fantastic work reach master as soon as possible. Once this makes it into master I am hoping Jan might come back. :)

Trying to develop further in a development branch seems to me a huge extra workload keeping the code in sync with master, and that time and energy would be better spent improving the code in Master.

I don't think we have a big enough development team, or more accurately not enough developer hours, to maintain different branches efficiently for long periods.

Of course Werner will have to decide on technical merits of this discussion but I am clearly in favour of merging into master as soon as possible.

Jim
User avatar
saso
Posts: 624
Joined: Fri May 16, 2014 1:14 pm
Contact:

Re: PartDesign Next

Postby saso » Sun Apr 10, 2016 2:12 pm

It si important to correctly understand the above suggested git branching http://nvie.com/posts/a-successful-git-branching-model/ it is not about following option 2 (further development in branches) it is about moving the master to the side and replacing it with one main "develop" branch. It should not represent any issues maintaining the two as long as strict rules are followed on the correct relation between the two. In a simple way we can say that what we did now in master we continue to do in the new "develop" branch and the master is just moved to the side, more like a "stable backup". Merging bigger changes to the main active branch (in current model it is master, in the new it would be the develop branch) becomes less critical and so more easy.

It makes no sense to adopt this model if we don't do it correctly, so it is important to understand and follow it exactly. I am proposing it so we can have a discussion about it, personally I believe it would be good. But for example we also don't have to do everything from it, it seems to me that for example the "feature branches" would probably work for us much better if we do them as we did until now, in separate user/developer forks, this lets us have a more simple, clean main repository with just main, develop and releases branches.
triplus
Posts: 5000
Joined: Mon Dec 12, 2011 4:45 pm

Re: PartDesign Next

Postby triplus » Sun Apr 10, 2016 2:51 pm

In plain terms currently we have master branch and a few separate development branches. I feel that FreeCAD 0.17 release cycle will be mostly focused on merging separate development branches in master and fixing things after directly in master. By doing series of small pull requests.

Once this is sorted out further development of any big planned changes could again be done in separate development branches.