-
Notifications
You must be signed in to change notification settings - Fork 15
Description
What is the problem your feature is trying to solve?
Consider removing the "v" prefix where Firmware Version is displayed on the UI, to allow for neater representation of firmware/software versions that may be 'letters' based, or concatenations of firmware and software as shown below.
Describe the solution you think would solve the problem
Adopt 'firmware version' as a heading as is done with the report PDF, to avoid the need to add the "v" prefix.
Additional context
The notion of "firmware version" alone is limiting (take a Niagara host as an example, the OS determines DHCP and ICMP functionality, but the (very user-configurable/per-project) software/station determines whether services like HTTP or NTP are 'in use'). I wouldn't necessarily advocate for separate fields to capture this, but the firmware version field could be overloaded as a workaround to capture all this information (as I've done in the example).
On a related note, whether an additional 'configuration version' or 'configuration reference' or similar field would be of benefit in the future I am not sure. Continuing on the Niagara front, I could configure 5 separate QNX 2.7.105 based hosts running Niagara 4.10.8.22 (and semantically capture that as the same 'firmware version' for all 5), but I could configure each of the 5 with wildly different services exposed, which might look a little strange from a report PoV when all 5 have differing results (despite showing the same captured 'firmware version').
Be interested to hear thoughts!

