Workbench Versions

[catman]

Design issue for discussion

FreeCAD_HelpAbout.png (143.63 KiB) Viewed 1315 times

Wouldn't this dialog be a terriffic place to have a tab "Workbenches" that lists all the versions of the workbenches?

Rationale:
The about box is the most logical place to get all version information of the installed SW in one place.
Today some can be found in the AddOn manager, but that has limitations. One is that in Offline mode, it displays nothing at all, including the installed workbenches. Another is, that some WBs have versions, e.g. Assembly4, others do not e.g. A2Plus (at least in the version in the picture above).

I guess this is not an urgent and important item, but just one more step towards a more sound product design.

[Kunda1]

FreeCAD_HelpAbout.png

Wouldn't this dialog be a terriffic place to have a tab "Workbenches" that lists all the versions of the workbenches?

Absolutely! I've been ragging on this point for a while. It's especially helpful for us here on the forum when we assist users to know if certain workbench versions they are using are in fact obsolete. The workaround has been to add the workbench version to the workbench dropdown name. But that isn't a long term solution.

[Kunda1]

Relevant:
https://github.com/FreeCAD/FreeCAD-addons/issues/105

[yorik]

The way I see how we could do it:

- Have an "Addons" or "Workbenches" or "Extensions" tab there, after "Libraries". Maybe Addons as it's the term we use already...
- That tab would list installed addon workbenches with, for each, data gathered from them such as authors and URL maybe?

We need to define how that list would be populated, ie. where would FreeCAD look for authors and URL... Maybe the metadata.txt that many addons already use?

[Kunda1]

- Have an "Addons" or "Workbenches" or "Extensions" tab there, after "Libraries". Maybe Addons as it's the term we use already...

Yea, that sounds good. The only thing I would suggest is that when the user clicks 'Copy to clipboard' that all relevant tabs get sent to the clipboard.

- That tab would list installed addon workbenches with, for each, data gathered from them such as authors and URL maybe?

Yes, hyperlinked.

We need to define how that list would be populated, ie. where would FreeCAD look for authors and URL... Maybe the metadata.txt that many addons already use?

This would be a great usecase and very good prompt to standardize all workbenches/addons/macros

[vocx]

...
Today some can be found in the AddOn manager, but that has limitations. One is that in Offline mode, it displays nothing at all, including the installed workbenches. Another is, that some WBs have versions, e.g. Assembly4, others do not e.g. A2Plus (at least in the version in the picture above).
...

The problem is authors basically have freedom to write their workbenches however they see fit. Unless we establish some hard rules, and actively enforce them, there is not much we can do.

See this discussion.

Add ons manager - development and bugs topic

...
If we enforce clear and strict Extension rules we can improve quality a lot and Extension developers will be interested in updating their extensions in order to be visible and installable.
...

I agree. I think we should define better rules to add workbenches to the addon manager.

See issue #164 in the repository.

People are free to create their workbench as they want, but if they want to be added to the addon manager, they should follow some clear rules.

We need more people willing to put in hours and days looking into the fine details of packaging workbenches, and even becoming maintainers of them, perhaps helping the original author.

In general, most workbench authors don't keep versions of their workbenches; they normally use a "rolling release" model, which means the "official" code is always the latest version. This works for simple workbenches that only do small tasks, but it doesn't work for more complicated codebases, where a new version may introduce new functionality previously not existing or which deprecates older objects. So, a big part of standardization is convincing authors that keeping their code versioned is beneficial to the overall FreeCAD ecosystem.

[catman]

The problem is authors basically have freedom to write their workbenches however they see fit. Unless we establish some hard rules, and actively enforce them, there is not much we can do.

I am sure the best system is one that includes that information without manual intervention.

How does FreeCAD get its Git revision number for the about dialog?
Is there a way to set up the repository to include this git number for a WB when downloading the code?

[vocx]

...
Is there a way to set up the repository to include this git number for a WB when downloading the code?

ping

Mnesarco, any updates from your side?

https://github.com/mnesarco/FreeCAD_ExtMan

Add ons manager - development and bugs topic

[sgrogan]

How does FreeCAD get its Git revision number for the about dialog?

FreeCAD runs a python script from CMake at build time that reads the commit history and counts from a known reference commit. The script then creates a version.h file that is "compiled in" to FreeCAD. I think into FreeCAD.pyd(so) but not sure of this.
The repo must contain the git info. A similar script could be run from the addon manager but this would make git-python and git hard dependencies of the add on manager. Now there is a fall back to download the .zip and extract. The .zip file doesn't have the git info.

[mnesarco]

Mnesarco, any updates from your side?

https://github.com/mnesarco/FreeCAD_ExtMan

Add ons manager - development and bugs topic

Hi Vocx,
I have not worked on this topic lately because i am solving a personal health problem that i hope will be solved soon by surgery, but of course I am still commited to provide a general document for Extensions standard. I have learned a lot from Anaconda in a current work project and i want to include the concept of "channels" so there can be multiple versions of the same extension depending on the selected channel.