add FEP01.md version-handling

[looooo]

@triplus @vocx-fc please help with concluding all the discussion which happened in the FreeCAD forum.

https://github.com/looooo/FreeCAD-Enhancement-Proposals/blob/version-handling/FEP01.md

[triplus]

Hi @looooo

Realistically i need some assurance first, for being prepared to invest more effort in this area:

https://forum.freecadweb.org/viewtopic.php?f=8&t=39928&p=408700#p408700

[looooo]

I know these kind of fights are a little bit destructive. But I remember debating namespace-workbenches in a similar way. In the end we found a solution. So I guess also here we should try to come to a conclusion. After all it's not so much about doing it sooner or later, it's more about defining when freecad should move to 1.x version.

And I guess if you find an agreement the rest of the community will accept. In my eyes having a target here is more important than finding the perfect solution. There is simple no such perfect solution and issues will always occure.

[triplus]

There is some amount of rational and irrational opposition involved, but i don't feel that comes down to being a fight. In addition i feel that it comes down to minority opposing and majority being in favor. Whoever participated in this debates over the years could observe the shift. When it comes to version number, especially 1.0, i feel that the ground work was already done in the past couple of years, discussing, and the common agreement has been reached (TopoNaming).

Trying to do more is in my opinion out of scope for now. My answer hence went more in the direction on what comes next, regarding possible version handling, things like introducing tags ... Maybe there FEP01 can play a role. The reality likely is a few years of effort will need to get invested by somebody, just like it was with FreeCAD modules, reaching 1.0 ...

[looooo]

In addition i feel that it comes down to minority opposing and majority being in favor. Anyway it seems that the discussion is somehow stuck and FreeCAD will be 0.x forever ; )

Why I came back to this topic: @vocx-fc wrote something about progressively moving towards namespace-packages, which I see too radical (today). I was in the same position some years ago (fighting for consistency and so on) but at one point one has to realise that compromises are necessary to keep traction. So I would like to see @vocx-fc to give those which wants a sooner 1.0 vision some hope and find a compromise. Toponaming will not arrive tomorrow and there is for sure plenty of time to optimize things after 1.0 is done. But from defining the version string it's also clear that the development-branch has to move to 2.0 once we released 1.0 as interface changes will definitely happen (which is for sure an argument against going to 1.0 too early).

[vocx-fc]

@vocx-fc wrote something about progressively moving towards namespace-packages, which I see too radical (today).

What? When? I would like to progressively move to namespace packages, but that doesn't mean quick and fast; it means slow and steady, that is what progressively means. And I never considered moving the base workbenches, because these form the core of the program. They could be moved to the new style but that effort is pretty big, and most programmers simply don't want to do it. But maybe the external workbenches would consider that shift, this is more realistic than moving the standard workbenches.

I mentioned in the the main thread where this is discussed. In my mind, we need around 5 years to reach 1.0, once a big chunk of realthunder changes are merged and tested. That's not a long time; it's sufficiently short, mind you. However, now we have more active contributors to the project, so actually we could shorten that time to 3 years if we keep improving the development pace, and more programmers join the cause.

But no matter what ideas you bring to the table, looo, triplus has made his mind. He won't change at all.

[triplus]

@looooo

The truth is all people involved in discussions this year, including @vocx-fc, more or less agreed, on what 1.0 development cycle should be all about. TopoNaming will arrive tomorrow, that is in the next development cycle. As for things like more documentation, more testing. I honestly don't see, on how anybody could disagree with that. For sure that can be a part of the next development cycle too. What i am trying to say is, there seems to be a perception of some in-depth disagreement, that is not the case.

@vocx-fc

Why should i change my mind if that doesn't make any sense? Anyway, if you are now OK, for 1.0 happening in around 3 years, then i feel this should finally be settled. As the next FreeCAD release won't happen before 2 and a half years, at best.

As for namespace packages. I guess this effort can evolve gradually. I don't see on why it should be bound to 1.0. Ultimately a module, such as Draft module, would need to be cut and pasted in Ext/freecad folder. I made an observation here:

https://forum.freecadweb.org/viewtopic.php?f=23&t=38593&p=408789#p408789

[looooo]

@vocx-fc

What? When?

I am referring to this post: https://forum.freecadweb.org/viewtopic.php?f=22&t=47460#p407656

so yes, if this is what you meant (slow and steady) then we agree on this. Anyway, in my eyes it's important to have the version-handling fixed before we can decide when it's best to work on porting workbenches to namespace-packages in my eyes trying to keep backward-compatibility is not possible for all workbenches doing this change). Therefore having this proposal drafted would be very nice.

I mentioned in the the main thread where this is discussed. In my mind, we need around 5 years to reach 1.0, once a big chunk of realthunder changes are merged and tested. That's not a long time; it's sufficiently short, mind you. However, now we have more active contributors to the project, so actually we could shorten that time to 3 years if we keep improving the development pace, and more programmers join the cause.

Ok, so topo naming is the key feature and once the approach from @realthunder lands in master and gains some stability this will mark the point where 1.0 should be possible (limited by 3 years if this will be reached earlier)

Actually I don't see many differences in both of your views. I guess 1.0 should be more about stability of functionality and restructuring/optimizing should happen after that point. This also means that we should keep our current way of handling the version (only patch-versions must be compatible).

For the restructuring, it would be nice to have some guidelines (of course there is pep8 but I guess we also need to create a few freecad-specific proposals to make the development of modules/workbenches a little bit easier.)

@vocx-fc I guess after all the improvements for the draft workbench you should have a good picture of the restructuring. So maybe you can work on a proposal on how to structure workbenches, commands and so on. One other point to work on is also a tool for automatically updating files from 1.0 to 1.1 or similar.

So my take is this: 1.0 will mark that functionality will not change drastically but it doesn't say anything about the stability of the API. To make progress once 1.0 is released we should now work on proposals and best practices to make it as simple as possible to apply this proposals once we arrive at 1.0. The cleaner we present the proposals the better others can work on them.