Better Reporting of the GUI Tool Version Numbers

[joshanne]

This is hopefully a change for the better.

I have team members running various versions of the main branch since the last release. I cannot tell exactly which version they are running because the application only tells me what version.py contains, which is typically updated just before the next tag and release is about to occur.

This PR makes use of setuptools_scm to improve the reporting of the version number.

The current build/release process entails:

1. Change the software version in version.py
2. Tag the release
3. Build and generate the release artifacts

This means, for all users installing from master after the last release, their build "looks" like the most recent release, but does not indicate that it is development patches on top of the last release.

This PR aims to improve some of that reporting.

All of this assumes the user has installed dronecan_gui_tool with one of the following methods:

pipx install .
python -m pip install .
uv pip install .
pipx install git+https://github.com/dronecan/gui_tool.git
python -m pip install git+https://github.com/dronecan/gui_tool.git
uv pip install git+https://github.com/dronecan/gui_tool.git

After which, one of the following outcomes occur...

# Release Version installed, check the version...

$> dronecan_gui_tool --version
DroneCAN GUI Tool is an application for DroneCAN bus management and diagnostics
DroneCAN GUI Tool Version: 4.3.2

# Clean Working Tree Version Installed, but not a tagged commit...
$> dronecan_gui_tool --version
DroneCAN GUI Tool is an application for DroneCAN bus management and diagnostics
DroneCAN GUI Tool Version: 1.2.28
Development Build: post43.g9f9737e40

# Dirty Working Tree Version installed, not tagged commit
$> dronecan_gui_tool --version
DroneCAN GUI Tool is an application for DroneCAN bus management and diagnostics
DroneCAN GUI Tool Version: 1.2.28
Development Build: post44.g4fba222d7.d20260724
Warning: Built from a dirty working tree!

Similarly, the version can be seen in the application.

Release Build:

Clean Work Tree, Development Build

Dirty Work Tree, Development Build

When locally running the build, you will now get the following:

$> ./bin/dronecan_gui_tool --version
Running from the source directory
DroneCAN GUI Tool is an application for DroneCAN bus management and diagnostics
DroneCAN GUI Tool Version: 1.2.28
Development Build: source-post45.g69793c2

I'm in the process of updating README.md - If this is accepted, the new Release Workflow should be updated to something like:

1. Create the Tag for the new version.
2. Push tag to repo
3. Build and release artifacts

[joshanne]

@tridge @Huibean do either of you have any objections to using this approach?

[Huibean]

Hi @joshanne can you solve the version v0.0.0 issue when launching the tool directly from source? others looks OK to me

[joshanne]

@Huibean if possible, would you like to give it another look over? I've updated the above images to show the developer build working the same way.

it simplifies the release process atm, no manual editing of files... there is still one edge case, but its very unlikely to hit now. It allows developers to run the tool from their directory and get the current commit information at runtime.

If @tridge or the release maintainer is okay to slightly modify the release process, the release process then becomes...

• Tag the commit
• Build and Release the artifacts

In effect, the steps for loading the version here are then:

• attempt to extract the information from git describe
  • if present, use the git describe generated version
  • if not present, attempt to use the generated version file from setuptools_scm
    • If present, parse the autogenerated version info
    • If not present, fall back to git_archival.txt file, assuming downloaded from zip file on github
      • if that file isn't present... THEN we default to v0.0.0.