name FreeCAD 0.91 instead of 0.20, means version after 0.19 could be 0.91

[Kunda1]

Folks, we just got a #history lesson and some orientation to boot

[chrisb]

I am intrigued to lock the topic and delete all posts after Werner's great response (+1s and I lock it).

[bernd]

I am intrigued to lock the topic and delete all posts after Werner's great response.

we could also come back to the origin topic: name FreeCAD 0.91 instead of 0.20, means version after 0.19 could be 0.91 or any other number near or over 1.0

BTW: more history can be found here: history

[bejant]

Just to post before the topic gets locked:
I like the 0.xx numbering convention FreeCAD has been using, and think a 1.0 release could wait until after Topological Naming has been implemented and proven successful...

[NormandC]

And I would like to thank Werner for the essential work he's been doing for FreeCAD for longer than anybody else here. Thank you for putting up with us, and thank you for occasionally cutting through the bullshit like you beautifully did now.

It used to be Jürgen's "job", but now that you're the "patriarch" it fell to you...

Look at the title of this thread. It is about the version numbering of future releases which was kept in a friendly and constructive manner until Zolko and you joined it.

I had stopped participating after Zolko's baseless and asinine accusation toward me.

[Mark Szlazak]

I am intrigued to lock the topic and delete all posts after Werner's great response (+1s and I lock it).

No i really do not think that would be appropriate quite yet. I would like to hear responses from the two people Werner addresses.

[kkremitzki]

PartDesign may be orphaned but that's just because its adoption papers are being held up

I'm interested in working on it but until someone else starts picking up some of the sysadmin and packaging workloads my time to work on it is limited.

(Still looking for a GSoC student!)

[wsteffe]

wsteffe wrote:
But this mine is just an other digression from the most important point: The FreeCAD project needs a project leader with a clear vision of the project goals and of the road to get there.

How did the German chancellor Helmut Schmidt once say? People with visions should go to the doctor.

That depends on the vision. In some situation somebody could tell that you are smoked while in an other one, if the vision was about the virgin, somebody else may propose you for a sanctification.

The vision I was speaking about is just a simple picture describing the FreeCAD architecture you would like to be realized.

I don't know when you started to work with OCCT. I made my first experiences 20 years ago with version 3.x when it was still a proprietary product and together with JRiegel we were working on an in-house product. At that time the viewer was simply not capable of handling huge data structures, especially meshes with e.g. > 500,000 triangles.
And at the very beginning of FreeCAD we also used this viewer but it turned out that we had to move to something more powerful. We decided to go for Coin3d -- an OpenInventor reimplementation. Alternatives were Coin3d, OpenSG and maybe OpenSceneGraph (I don't remember how mature it was at that time) but Coin3d was the most advanced system at that time.

It's rather the other way round. Coin3d offered a lot of more features you never got with OCCT (unless you implemented all this on your own). The one and only advantage of the OCCT viewer over Coin3d I remember was that it had a ready highlighting/selection system. But the effort to get something similar with Coin3d was not that much.
And why do you think that other projects like Salome additionally use the vtk viewer? Because the OCCT viewer was so great?
I think in the meantime the OCCT viewer has improved -- maybe since the developers decided to also use vtk? I don't know.

Ok. I was wondering why you have choosen a visualitazion tool such as Coind3D which deals with an Open Inventor scene graph instead of going with the OCC internal viewer which may handle directly the OCC objects. After having written those words, I had already seen your explanation for that in an other thread and I may agree that the OCAF data structure is quite obscure, bad documented and difficoult to customize. I could accept these drawbacks because in my application a I do not need to make a limited processing on the imported CAD file which is soon meshed and then the mesh is viewed using gmsh. Anyway, as you also said, the OCC project evelved in the last 20 years and I have seen (at page https://dev.opencascade.org/doc/overvie ... ation.html) that now it is possible to use V3d_Viewer to visualize a simple OCC shape without involving OCAF. So may be that, you could also reconsider V3d_Viewer as a possible replacement of the obsolete Coind3D library. But this is the matter of an other thread ...

Regarding Salome it is a essentially a meshing tool and I think that they use the vtk viewer to visualize the meshes (as I do with gmsh) but they still use V3d_Viewer for CAD geometry. Not very sure about my laste statement, I have to check.

Look at the title of this thread. It is about the version numbering of future releases which was kept in a friendly and constructive manner until Zolko and you joined it.

That is just because, in my opinion, discussing the version numbering without taking into account the project status and its evolution doesn't make much sense. If the version number were independent from the project status I would say "Set the version number to 1.0" so that we are finished with the beta phase and FC suddenly becomes a production software".

When looking at the history of EmCAD then you haven't contributed to it for more than 3 years. So enough time to have participated here in a constructive manner if things don't go fast enough for you.

Actually I made a lot of progress with EmCAD in the last 3 years but not yet published. I would like found to update the documentation before uploading last release and I did not find the time for that.

Btw, have you ever worked on an open-source with more people involved than yourself? Do you really think you can force people to work on certain areas they don't really understand/need/whatsoever? Once you start with this you cannot look fast enough and a community project turns back into a one-man show.
So, you have to be happy with the people who join and offer their spare time to work on functions they want to see improved. If you want professional structures then at some point you have to pay the people.

No I never worked on open-source projects involving other people. But I am not proposing to force people. I am just proposing you to make a clear picture/road map that other people may choose to follow or not. And, considering the great approval you receive from your posts, I am quite convinced that many will follow. Maybe somebody will object to a specific archietectural choice and his objection will be discussed and approved or rejected. I am not asking you to make a final picture that never changes but a draft one which will evolve along the FC project.
I think that this picture should set the basic requirements for all the core elements of the FC asrchitecture and these requirement should be defined (as much as possible) having in mind the user perspective. I think that many of these requirements could be simply derived from the experience with existing CAD products but this doesn't mean that a new original design flow must not be proposed.

To make a simple example let us consider the assembly module. Do you agree that an assembly should be built trough the linkage (not copying) of preexisting parts ?. Which, I think, is the norm in most other CAD systems. If you think that FC should follow this common rule you should put it in the requirements. Otherwise you may think that FC should make something different (as it is done in A2plus). Also in this case the choice should be clearly stated but, perhaps, with some additional analyses which demonstate the advantages of this new proposition versus the traditional approach.

Realthunder asked me exactly once to have a look at the Assembly stuff.

There was a long thread on this subject with the involvment of many developers and an apparent indifference to this subject from your side.

And seriously what else do you expect from me? I have to check the majority of PRs, fix bugs listed in our bug tracker, make sure that FreeCAD compiles on a wide range of different platforms with different versions of libraries, participate on several development discussion, help newcomers to get their things done who use the FreeCAD API, look through the results of code checkers regularly offered by saso to improve code quality, ... while for several years I have nearly no time any more to implement the stuff that I am interested in.

I would expect that you spend a little less time in discussing/reviewing low level issues and a little more time in the definition of the FC architecture. In my opinion the choice about the structure we want for the Assembly module is much more important than a discussion on how differenly the strings must be handled in python3 versus python2.

[wmayer]

Just to post before the topic gets locked:
I like the 0.xx numbering convention FreeCAD has been using, and think a 1.0 release could wait until after Topological Naming has been implemented and proven successful...

As far as I remember from discussions with Jürgen the plan to switch to version 1.0 was when the most important issues are solved:
it's the topological naming as you said and the assembly workbench.
freecad-heini-1 has reported in other threads that the topological naming done by realthunder already works pretty well and only fails in some tricky cases. So, this sounds good.
And realthunder is also working hard on the assembly which freecad-heini-1 and others have reported about that it looks quite mature, too.

So, the next step for me will be to go though the long list of pending PRs and then see how far realthunder will be with rebasing his branches. Then I hope to dedicate my time mainly on these two issues.

And I would like to thank Werner for the essential work he's been doing for FreeCAD for longer than anybody else here. Thank you for putting up with us, and thank you for occasionally cutting through the bullshit like you beautifully did now.

Thanks. And I thank the whole community for its effort in contributing to FreeCAD by helping people with their problems, helping on the translation and documentation, preparing all the installers and packages or keeping our services like forum, bug tracker in shape and last but not least: for contributing code.
FreeCAD would be nowhere without so many helping hands!

It used to be Jürgen's "job", but now that you're the "patriarch" it fell to you...

Yes, he was actually the ideal guy because on the one side he had detailed knowledge about software development and architectures and on the other side he had a good understanding of the concepts how CAD systems work.

[wsteffe]

freecad-heini-1 has reported in other threads that the topological naming done by realthunder already works pretty well and only fails in some tricky cases. So, this sounds good.
And realthunder is also working hard on the assembly which freecad-heini-1 and others have reported about that it looks quite mature, too.

But, if topological naming and assembly developed by realthunder are considered mature and the two topics are recognized as the most important issues for a switch to 1.0, why triplus (see below) asked realthunder to separate these two parts before merging and nobody has objected to it ?
If both are soon to be merged why should we ask realthunder to loose his time with this separation ?

extracted from last triplus post in thread "assembly3 preview":
"P.S. As for the TopoNaming. I know you would like to combine all this in one scope. I feel that such approach could introduce more confusion and issues regarding QA and would prolong the review process. Technically Link doesn't need TopoNaming solution? That is, if people start using Link functionality, for things like adding standard parts from external library to an assembly. That should already be rather robust, without the TopoNaming solution? For purposes, when the topology is expected to change, like LinkDeep, and other use cases in FreeCAD. For that TopoNamning solution starts to make more sense. And when it comes to the TopoNaming effort, i feel that things should still mature a bit more. If developers like @ickby would get involved and after more discussions and understanding would happen ... There is still a chance it could get tackled in the current development cycle. But lets do the Link first, and worry about the rest latter?"