Release Manifest file doesn't provide THISFIRMWARE string

[rmackay9]

It seems that the manifest file (https://firmware.ardupilot.org/manifest.json) does not provide the THISFIRMWARE string meaning that the Ground Stations that use it can't retrieve the human readable version string (i.e. "ArduCopter V4.0.2-rc3"). The "-rc3" part in particular is missing but important for users.

[meee1]

also the name on heli builds

[peterbarker]

On Sat, 1 Feb 2020, Randy Mackay wrote: It seems that the manifest file (https://firmware.ardupilot.org/manifest.json) does not provide the THISFIRMWARE string meaning that the Ground Stations that use it can't retrieve the human readable version string (i.e. "ArduCopter V4.0.2-rc3"). The "-rc3" part in particular is missing but important for users.

Not currently supplied in the firmware-version.txt files we're parsing to create the manifest.json files, so fixing that is a prerequisite. The mavlink standard says this: <enum name="FIRMWARE_VERSION_TYPE"> <description>These values define the type of firmware release. These values indicate the first version or release of this type. For example the first alpha release would be 64, the second would be 65.</description> <entry value="0" name="FIRMWARE_VERSION_TYPE_DEV"> <description>development release</description> </entry> So we can switch to using numerical values in the type field, or go with "FIRMWARE_VERSION_TYPE_RC" for rc1, FIRMWARE_VERSION_TYPE_DEV+1 for rc2. I'm not sure, but I think it may be possible that changing #define FIRMWARE_VERSION 4,0,2,FIRMWARE_VERSION_TYPE_DEV to #define FIRMWARE_VERSION 4,0,2,FIRMWARE_VERSION_TYPE_RC+2 would be sufficient to get that information through. Doing this allows us to represent multiple 4.0.2 firmwares unambiguously in the manifest.json metadata, no parsing requiref for the GCS. More investigation required.