Issue in current FreeCAD dev.-version

[FreeCutter]

Hi, when adding a new assembly in current FC dev. version (see further info below) the report view gives these errors:

15:31:05  Running the Python command 'Asm4_newAssembly' failed:
Traceback (most recent call last):
  File "C:\Users\...\AppData\Roaming\FreeCAD\Mod\Assembly4\.\newAssemblyCmd.py", line 84, in Activated
    lcs0.Support = [(assembly.Origin.OriginFeatures[0],'')]

'Part.Feature' object has no attribute 'Support'

Can we hope that Assembly4 will be further developed so that it can continue to be used with the current FC Dev. version or the next release?

FreeCAD Version:

OS: Windows 10 build 19045
Word size of FreeCAD: 64-bit
Version: 0.22.0dev.36391 (Git)
Build type: Release
Branch: main
Hash: 52fffaf50ef8facea2ecfde23d6f1a7d3ad3d80c
Python 3.10.13, Qt 5.15.8, Coin 4.0.2, Vtk 9.2.6, OCC 7.6.3
Locale: German/Germany (de_DE)
Installed mods: 
  * Assembly4 0.50.9
  * CurvedShapes 1.0.5
  * Curves 0.6.28
  * fasteners 0.5.14

[Zolko-123]

For now I suggest you use FreeCAD's stable version 21 (or even 20)

[3x380V]

Fix is waiting at https://github.com/3x380V/FreeCAD_Assembly4/commit/d959a7457bf1c1661143d7095fc5619c5de75221 After https://github.com/FreeCAD/FreeCAD/pull/14494 merged, development versions should be ready to use again. There is still https://github.com/FreeCAD/FreeCAD/issues/11958 pending, but that is not critically important. Of course file saved with this version cannot be open in 0.21 and earlier, but there is macro for conversion available.

@Zolko-123, in case you consider supporting bleeding edge mainline again I can prepare PR based on my devel branch above.

[leoheck]

Thanks, @3x380V nice work making things work again on the bleeding edge.

[Zolko-123]

@3x380V : can you please make PRs against de development branch (and not Main) and separate the commits in as much PRs ?

[Zolko-123]

@Zolko-123, in case you consider supporting bleeding edge mainline again I can prepare PR based on my devel branch above.

can you please do that with separate PRs for each commit ?

[Zolko-123]

Thank-you. I think that this is fixed now with latest FreeCAD v0.22 (Version: 0.22.0dev.37573) and latest Assembly4 (0.50.13)

[3x380V]

I do not follow weekly builds, so it is a bit time consuming to reveal what's inside. However current master loses all attachments when loading files created with versions prior to rename Support to AttachmentSupport. To make that work https://github.com/FreeCAD/FreeCAD/pull/14494 needs to be merged.

[Zolko-123]

Why doesn't anybody complain about that ridiculous decision ?

[3x380V]

Till these days problems with ShapeBinder which leaded to said rename keep popping on the forum, so it seems that it solves the real problem. I do not have deep enough knowledge of FreeCAD internals to judge whenever there was more suitable solution available (@realthunder did the same in his fork, btw), but it was already done, so the only thing left to do here is to deal with consequences. This is solely FreeCAD problem, Assembly4 informs about it in the README.md and that is basically all that can be done.

A honest try to answer your question: people reading forum are mostly unaware of internal details, people reading github do not particularly care about one extension of many, so here we are.

[Zolko-123]

@realthunder did the same in his fork, btw

I know, or I'd have switched to it

As for your honest answer, thank-you but you missed a point: what about maintainers ? How does one become a maintainer ? So the problem is actually much worse than what you say: it's not an unfortunate bad decision, but FreeCAD has been overtaken by incompetent careless people, and that is a terminal situation for any technical project, and leads for open-source projects invariably to forks. Always.

I don't have time currently but I have already secured the FreeCAD v0.21.1 source code for long-term maintenance. I don't think that the current FreeCAD version will go very far

[3x380V]

You already answered yourself. Forks need manpower to keep going and there is not enough manpower for FreeCAD itself, so your fork needs to attract more developers. I already wrote that very same thing on the forum and there is nothing to debate. Fork needs to prove its vitality and talk is cheap. Perhaps you are on the doorstep of successful fork, nobody would ever know without giving that a try... You might argue with talent. Yes, single talented developer is capable of many things, but project dies with him way too often and after three decades of contributing to the OSS I do not see any big drama here, at least not that big to justify all that extra work involved. After all, code stays with us, that's what copyleft licenses are all about: protecting users.

[Zolko-123]

The important thing is "compatibility". This is especially important for open-source since that's the very only imparable argument that open-source has : the promise of open-source is that the data is yours, and you'll be able to access it for eternity.

FreeCAD v0.22 broke that promise. And without even discussing it, as a matter-of-fact. And, if I'm not mistaken, without also warning the users in the v0.22 (or v1.0) changelog.

As you say, talk is cheap and time will tell.

[3x380V]

Just released 0.22.0dev.37819, hash: 2ca9b6ef8036d5fd808f01205b66eb0424059e21, contains before mentioned fix, so FreeCAD is able to open files created with previous versions. Together with changes in Assembly 4 development branch mostly everything should work as usual. There is still problem with in place editing (FreeCAD problem), so lets see whenever this can be fixed too.