triplus wrote: ↑Thu Feb 20, 2020 3:57 pm
...
Would this do for us or am i missing something? Backport releases would therefore bump the MINOR number and stable releases obviously would bump the MAJOR number...
I disagree with this. This is actually related to the next paragraph.
... Currently i must say i am leaning towards the idea that semantic versioning puts way too much emphasis on the API, it's basically all about the API...
Actually, my idea is that since FreeCAD can be used as a library, it should be treated as one. The programming interface is the most important part of it, and it's what gives stability to the whole project.
Modelling things with the mouse is of course possible, but once you understand how to use the programming interface, that's the key to unlocking the power of FreeCAD through scripts that automate modelling, and of course, writing
external workbenches. Without a solid programming interface, this is not possible.
So, to me semantic versioning makes the most sense.
The future 1.0 should have a stable API that we can rely on. Precisely in my other thread, I would like to stabilize the API, before we think to even move to 1.0. So, each new yearly version would be 1.1, 1.2, 1.3, 1.4, etc. They would build on top of the stable API. If we decide to break compatibility, then we should move to 2.0.
We shouldn't bump the major number every year, because that would indicate an API incompatibility every year. Or we may end up with this situation, "version 1.0 and 2.0 are API compatible, then 3.0, 4.0, 5.0, 6.0, are API compatible, then 7.0 to 9.0 are API compatible, then...". It doesn't make much sense to me, and will become hard to manage once there are many versions.
To be API stable you have to think about all workbenches, not only about the core C++ functions, or those provided by the App:: namespace. Think about Path, Draft, Arch, FEM, Sketcher, TechDraw, Part, PartDesign, at least.
triplus wrote: ↑Thu Feb 20, 2020 3:57 pm
In addition if we would use PATCH number for backport releases, what would we use MINOR number for?
No. We would use MAJOR for major stable API releases. Then MINOR for updated releases (yearly), and PATCH for bug fixes.
This year's release could be 1.5. Then backported bug fixes would be 1.5.1, 1.5.2, 1.5.3. Next year's release would be 1.6. Then we make bug fixes to both releases, 1.5.4, and 1.6.1. Next year, a new version, 1.7. Bug fixes 1.5.5, 1.6.2, 1.7.1. Obviously, at some point we have to drop support for old versions.