Why are we rushing to call the next version already the 1.0 version?triplus wrote: ↑Thu Feb 06, 2020 7:38 pmThanks for the report and indeed, best if you take a break for a while. Next development cycle will likely be FreeCAD 1.0 oriented and your work should fit nicely in it. ...
It's done when it is done, as for future planning. I somehow feel that the maximum amount of time, dedicated to FreeCAD 1.0 development cycle, should be 2 years. ...
There is a pull request opened almost a year ago just to announce that the 1.0 version is surely upon us, #2048. But why? What's the rush?
In my opinion, FreeCAD is still a few years away from being a true 1.0 software.
- App_Link is still being investigated by everybody who is using Assembly3 and Assembly4. There isn't enough people right now who have tested these workbenches. New ideas and methods to work with them are still coming. Realthunder has several commits still waiting in the queue to solve some issues introduced by his branch, and Werner of course needs time to solve the issues he identified previously.
- The topological naming problem is still not solved. The solution to this could come in the next cycle, 0.20, after extensive code changes and modifications, just like it happened with the LinkMerge. That will require another year of tests and fixes. See realthunder's Topological Naming, My Take.
- The documentation is still far from complete. New tools in Path and TechDraw are still being added regularly. Moreover there is a ton of power user and developer documentation that hasn't been significantly updated in years. Most code examples in the Power users hub and Developer hub are quite old and untested with a modern version of FreeCAD. I myself have made thousands of edits over the past year, and I am still not satisfied with the state of the documentation of the workbenches I use the most, like Draft, Arch, TechDraw, PartDesign. Also, Yorik was planning of moving the documentation to some git-based platform instead of a wiki. That takes time as well.
- The FreeCAD API, https://www.freecadweb.org/api/, is still lacking severely. We still need to find a way for documenting Python workbenches better, either with Doxygen, or using Sphinx+Doxygen (Breathe).
- I have mentioned in the Draft subforum that to me a 1.0 version could come at the soonest in five years, that is, 2025. We need significant time to refactor some code, and establish some more rules governing FreeCAD, including the use of looo's FreeCAD enhancement proposals (2), or things like the Workbench-Starterkit (2, 3). I'd also like to propose a more Pythonic interface for the functions, so that they follow PEP8. In the Draft subforum I have mentioned that the old functions could be retained as aliases of the new functions, but eventually we could break this compatibility (in about five years, in the hypothetical 1.0 version).
- I still think there is some value in defining and polishing a set of standard or core workbenches, in order to build FreeCAD around those. The fact that both Ship Workbench and Plot Workbench are now external to FreeCAD means that this was somewhat of a good idea. We should keep in the master repository only those workbenches that are truly central to the objectives of the program, and not just any workbench.
A previous thread where some of these ideas were discussed is name FreeCAD 0.91 instead of 0.20, means version after 0.19 could be 0.91. I didn't give my thoughts in that thread, but I think it was interesting, and a good read despite the heated arguments at times.
On the topic of the version, I personally prefer to do a simple jump, 0.20, 0.21, 0.22, etc. And when we feel we are ready, then move to 1.0. But let's not rush it.