Discussion: FreeCAD is not ready for 1.0

[bernd]

BTW:
In FreeCAD it's done when it's done. In commercial cad some needed tools will just never be implemented, even if the software is on version 10 or 25

[bernd]

Ahh, for FEM I do have a clear road map, but just not the spare time to do all of this in myself given time range including bug fixing and all other stuff which needs to be done.

Furthermore the road map changes if some other is willing to implement some feature which I find useful. Than I do support this and this changes my own given road map.

As werner said, if someone really needs some tool he would need to pay a developer to implement this. Than they have a contract and they even can have a time table for the implementation.

[triplus]

I feel that over the past couple of years we have done the ground work and have discussed things regarding 1.0 in much detail. I don't really feel it makes much sense now, to continue to do that, or to try to persuade anybody to believe otherwise, to whatever one believes. Sure, there are a million things, that could still be done before, but lets keep it real. People that want to assemble with FreeCAD, can now do that, this therefore can't continue to be the sole reason, to not do 1.0. In general there is an agreement, on what will get upstreamed in the next development cycle, and in general we have reached an agreement, it's worthy of calling such development cycle a 1.0. In real life it doesn't get much better than that.

Hence, what to expect to happen next, is to release FreeCAD 0.19, by the end of 2020. After to start the next development cycle, 1.0 oriented, and realistically to expect it to be finished in 2 years time. Such plan doesn't go against anything that was said in this thread, and if somebody feels strongly about some aspect, there is plenty of time available, to work on it, therefore go for it.

Around 2023 therefore FreeCAD 1.0 will get released and that is that.

[Zolko]

Hence, what to expect to happen next, is to release FreeCAD 0.19, by the end of 2020.

where did you get that information from ?

[vanuan]

As a hobby user, I think the only difference between 1.0 and 0.19 other than a perceived "stable" state, is the ability to do more frequent releases, e.g. 1.0.1, 1.0.2. If 1.0 doesn't mean that bug fixes would be backported more frequently, the version number doesn't matter to me. So to me, streamlining releases is more important. The nightly 0.19 AppImage updates have been awesome so far. It would be great if those receive a regular version number weekly or biweekly.

So, rather than focusing on what would be done in which version, it's much better to have a predictable schedule for the contribution delivery. Of course, that would mean things would break more often. So some automated crash reporting/rollback is needed.

[triplus]

where did you get that information from ?

Based on what other key people said in such discussions and based on the past experience with a release cycle.

As a hobby user, I think the only difference between 1.0 and 0.19 other than a perceived "stable" state ...

As for "perceived state", yes, that alone has become a strong argument, for doing a 1.0. For both hobby and professional usage.

[kkremitzki]

As a hobby user, I think the only difference between 1.0 and 0.19 other than a perceived "stable" state, is the ability to do more frequent releases, e.g. 1.0.1, 1.0.2. If 1.0 doesn't mean that bug fixes would be backported more frequently, the version number doesn't matter to me. So to me, streamlining releases is more important. The nightly 0.19 AppImage updates have been awesome so far. It would be great if those receive a regular version number weekly or biweekly.

So, rather than focusing on what would be done in which version, it's much better to have a predictable schedule for the contribution delivery. Of course, that would mean things would break more often. So some automated crash reporting/rollback is needed.

Strongly agreed.

[vocx]

...
it's much better to have a predictable schedule for the contribution delivery. Of course, that would mean things would break more often. So some automated crash reporting/rollback is needed.

One of the things that I mentioned in this thread is that I would like to see more constant releases of FreeCAD; 6 to 9 months seems feasible at the current developing pace. That would imply that there is constant work, constant testing, and it would invigorate the entire community. As it is currently, it feels a bit slow when the "stable" version is more than a year old, and the next version is already so far ahead that you cannot compare them any more.

As it is right now, triplus is essentially suggesting to take two years to develop something, and just release it as 1.0 at the end of it. I would much rather have 4 versions in between that.

[Zolko]

where did you get that information from ?

Based on what other key people said in such discussions and based on the past experience with a release cycle.

Ah, from your little finger

One of the things that I mentioned in this thread is that I would like to see more constant releases of FreeCAD; 6 to 9 months seems feasible

I agree, but then, let's round it and do a release every year. Should be feasible, and would solve the versioning question. Like Covid-19 was released in 2020, we should make FreeCAD 19 in 2020 (yes, I know that Sliptonic has made that joke first).

[vanuan]

Please also consider the issue of backporting. For example, when a user reports an issue, developers can't just tell "it's fixed, now wait for a year for the fix to be released". So developers must do some backporting. But sometimes backporting just can't be done. And with a gap of one year, it is more often than not, that backporting is impossible or requires more work than the original fix.

What's so wrong with having multiple channels of regular releases, "stable" and "dev"? Each channel would lag behind the other by some amount, say one month, 6 weeks, etc. If some feature is not ready, it is a common practice to hide it behind the feature flag. Is it a problem of Linux distribution cycle, lack of CPU resources, or what? What's the current process of "stabilization"? And why it can't be done on a regular basis?