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

[Joel_graff]

So this discussion is really about our development roadmap. And it seems to me we need to get serious about laying that out more explicitly if we spend this much time discussing version numbers and the elusive '1.0' release. In scheduling terms, we need a 'critical path' - a list of things which must occur (and the order they must occur in).

I suggest we get community consensus on the following points (for as much as that can be done):

• List the features / bug fixes that would make an FC release worthy of the tag 'v1.0' . NormandC's list looks like a good place to start.

• Prioritize the list. Whether it's determined by how important the feature is, or how close it is to being done - whatever.

• Build a development roadmap around that list, establishing certain features be complete before certain versions may be released.

So, for example, if we break NormandC's list into five key categories, we can then identify five 'major' releases between now and version 1.0 and associate very specific features which must be met in order to make the release.

Of course, nothing is set in stone, but it gives us goals and makes it clear what's really important to the project, so we spend our time working on things that really move FC forward for the sake of the community that depends upon it.

I really don't care what versioning scheme we use, and I know we can't predict the future or make guarantees ("it's done when it's done," after all), but if we really want to make version 1.0 a reality, we need to be more intentional about our development roadmap.

Incidentally, the current roadmap in the wiki leaves a lot to be desired... A critical path to v1.0 would make it a much more useful (and maintainable) document.

[NormandC]

Discussing a roadmap and prioritize a list is all fine and should be done, but if there is nobody to implement it... The PartDesign workbench has been orphaned for 18 months. It's benefited from bug fixing in the 0.18 development cycle but nothing more. realthunder has done some work but it all sits in his separate fork...

[abdullah]

So this discussion is really about our development roadmap. And it seems to me we need to get serious about laying that out more explicitly if we spend this much time discussing version numbers and the elusive '1.0' release. In scheduling terms, we need a 'critical path' - a list of things which must occur (and the order they must occur in).

We need a development roadmap but a development roadmap is not related to a certain version number. My point is that we do not need to have a 1.0 version to have the same features under "1.0 release". These features will live happily ever after under a 0.20 or 0.22 or 0.30 numbering. In so far as this thread should not treat version numbers, the title is rather misleading.

I think it makes sense to define a critical path for the most needed functionalities. To complete your same idea from a different angle..

For each of them, we can talk about the main problem(s) to solve, define prerrequisites and then "do it the FreeCAD way", i.e. wait for somebody to come with an all-in-one architecture-highleveldesign-detaileddesign-halftested-implemention that will be reviewed before merging. After merge, it will undergo "black-box" testing and hopefully after several bug fixing iterations it will ready-ish for the following release.

In my opinion, the waiting part should be "Put it in the bug-tracker" and assign it to a roadmap version. This makes clear what we would like to eventually get. During the subsequent development cycles part of the features will catch the eye of somebody and eventually we might arrive to complete that critical path. Some features might be pushed to the following development cycles several times before a developer decides to go for them, but at least that previous work won't be lost.

[triplus]

If having an assembly module, to get to FreeCAD 1.0, is the set criteria, then i guess we are talking about upstream assembly module. As FreeCAD has had assembly module(s) for years now. When it comes to upstream assembly module, there actually is one, but it isn't functional. I mentioned this fact, because when it will become functional, that is, it will have an useful feature or two in it. Will that be enough? Or should it at least support inverse kinematics first.

Therefore "assembly criteria" is a bit debatable criteria in the end. Likely it was set in times, when it was expected, this will be a rather straightforward process, and in a couple of years it will get done. That is there will be some relations in an Assembly workbench and people will be able to use them for assembling purposes. This in the end has happened already, just not in one of the default workbenches.

Anyway, from past discussions, on why we have this discussion in the first place. Some feel using a number below 1 isn't suitable anymore. As FreeCAD is matured enough project now. Majority of participants expressed, number representing a year of release or development cycle works good for them. Hence the number in the next version, that would address both aspects, would i guess be FreeCAD 1.19.

P.S. I personally wouldn't have problems with FreeCAD 2019. I just don't know if the year should represent a development cycle or a release year. Likely representing a release year makes more sense. FreeCAD 0.18 would therefore become FreeCAD 2019. And current development cycle would produce FreeCAD 2020.

[Joel_graff]

Anyway, from past discussions, on why we have this discussion in the first place. Some feel using a number below 1 isn't suitable anymore. As FreeCAD is matured enough project now. Majority of participants expressed, number representing a year of release or development cycle works good for them. Hence the number in the next version, that would address both aspects, would i guess be FreeCAD 1.19.

From a PR ('public relations', not 'pull request' ) perspective, using round, whole numbers is unquestionably better. I know FC does get judged for using '0.xx' versioning. I've seen a number of comments that say things like 'It's version 0.xx, so you know it's probably not any good..."

From a development perspective / community perspective, "v1.0" really represents something significant to all of us, though obviously it means different things to different people. This is why I mentioned the development roadmap - if we stick with the "0.xx" scheme (in hopes of making it to "1.0"), then we should outline exactly what we need to justify calling a release "v1.0" - because that seems to really mean something to us and because we do get judged as inferior by the version number alone, so long as we continue to use 0-based versioning.

If, on the other hand, we just start calling it FreeCAD 20xx (or whatever) and move away from 0.xx versioning, then we avoid all of that. We no longer have to worry about getting to "v1.0" or whether or not FC is production-ready. It just is what it is and it's done when it's done.

I have no real opinion, honestly, but I see advantages for the community going either route.

[bernd]

We need a development roadmap but a development roadmap is not related to a certain version number. My point is that we do not need to have a 1.0 version to have the same features under "1.0 release". These features will live happily ever after under a 0.20 or 0.22 or 0.30 numbering. In so far as this thread should not treat version numbers, the title is rather misleading.

For me this topic is all about version numbers. I do not care about features in this topic. For me we gone have enough features even for a version 2 or 3 or 10. I just would like to get a higher version number!

From new user I get questions. I do not use beta software, FreeCAD is not ready bla bla because of version 0. If I tell them hey it is just a version, FreeCAD is no beta ... I get back and why does it have a version number of 0.1x ... This gets even worse if it comes to business users or companies I tell about FreeCAD. It gets even more worse if people do not know much about software development and open source in general but just use software or decide which software should be used in the company.

A version number above 1. or at least near 1. is much better to sell to other people. If the community decides to go the way as is is I just will have continue to explain "FreeCAD is no beta software" for the rest of my live ...

Never-less we run into a good discussion about features and future of FreeCAD which is worth to be continued.

cheers bernd

[bernd]

Ahh and as Werner is not stopping to say "FreeCAD will never be finished" I really like this because it is true.

Development will go on and go on, no matter if we gone have assembly or not or have assembly5 or 6 or 4+newgeneration_updated. No matter if we have version 0.20, or 2020 or 2.0 or 20.0 or whatever.

[easyw-fc]

For me we gone have enough features even for a version 2 or 3 or 10. I just would like to get a higher version number!

From new user I get questions. I do not use beta software, FreeCAD is not ready bla bla because of version 0. If I tell them hey it is just a version, FreeCAD is no beta ...

+1

A version number above 1. or at least near 1. is much better to sell to other people. If the community decides to go the way as is is I just will have continue to explain "FreeCAD is no beta software" for the rest of my live ...

+1+1 again

[abdullah]

For me this topic is all about version numbers. I do not care about features in this topic. For me we gone have enough features even for a version 2 or 3 or 10. I just would like to get a higher version number!

From new user I get questions. I do not use beta software, FreeCAD is not ready bla bla because of version 0. If I tell them hey it is just a version, FreeCAD is no beta ... I get back and why does it have a version number of 0.1x ... This gets even worse if it comes to business users or companies I tell about FreeCAD. It gets even more worse if people do not know much about software development and open source in general but just use software or decide which software should be used in the company.

A version number above 1. or at least near 1. is much better to sell to other people. If the community decides to go the way as is is I just will have continue to explain "FreeCAD is no beta software" for the rest of my live ...

Ok. I do get your point and Joel's.

If from a PR point of view we are to drop the traditional dot versioning, then I think it makes sense to go to year version, like FreeCAD 2019. I never really liked this "20XX" use, but at least it gives an impression of when it was released.

[looo]

-1 for 0.91 (doesn't make sense to me)
+1 for 20xx. This way we can go directly to 2020 (and accept that there are always parts which are not 1.0)