On my EMX and G120 releases I have the app name contain the firmware version it was build with (eg App_4.2.10.1_20211213.HEX), and when an IFU is requested the running app checks which version of firmware it is installed on, if it matches the new app name just the app is installed, if not it searches subdirectories for the matching version and installs that firmware along with the new app.
This allows for easier forward and backwards version IFU update by clients.
With TinyCLR I can use DeviceInformation.Version to return a 64-bit ulong, which can be broken down into four 16-bit numbers, so currently 2.2.0.5100 in decimal, where the least significant number is 0x13ec.
If I use InFieldUpdate.VerifyFirmware I get a 32-bit version number, which can be broken down into four 8-bit number as 2.2.0.51. So to compare them I would have to take the last of the four 16-bit numbers, expressed as decimal, and divide by 100, to get a match for the last segment of the version.
If we are using Semantic Versioning, ie Major.Minor.Patch.Build, then I should only have to match the first two segments of the version number, Major and Minor, to be confident my app would work with the installed firmware.
Is this this the case with TinyCLR?
If not, how close a match is required - Patch level as well? And surely not build?
As a side note, for the App internal version number I prefer to use Microsoft’s format where you set it to 2.2.*.* and Visual Studio automatically encodes the build date into the the last two segments. This makes the build date easy to extract and display from your application. And if only Major and Minor are required it should also work in with the VerifyApplication() IFU call.
@Dat_Tran Do you mean the last two digits of the decimal representation (ie the 00 at the end of 5100) are always zero for the user, so the next user version would be 2.2.0.52, or the last two numbers are always zero, so the next number for the user would be 2.3.0.xxxx ?
If the latter then a version match between firmware and application of the first two numbers (ie any 2.2.x.x application works with any 2.2.x.x firmware) to comply with semantic versioning.
Or if the former, you need to match in all four version positions, so app 2.2.0.51 only works with 2.2.0.51 firmware?
“so the next user version would be 2.2.0.52” => depends on what we changed. But yes, 2.2.0.5100 will change to 2.2.0.5200 if there is a smallest change, even just rebuild.
“so app 2.2.0.51 only works with 2.2.0.51 firmware” => The app version comes from users, independent of our firmware version.
If you are talking about nuget then yes, firmware and library have 2.2.0.5xxx will work because there is no changed API.
As per my first post, the App_x.y.x.n_yyyymmdd.hex number used in the file name I am talking about refers to the NetMF SDK it was built with, not the internal user version number which is quite different (we use Major.Minor.*.* based on the board hardware version, software version, and build date/time).
So App_4.2.10.1_20211213.HEX was built with GHI NetMF SDK 4.2.10.1 on13 Dec. 2021.
If you want to refer to that as Nuget or Library that’s ok. I’m hoping to retain the same file-naming system with TinyCLR.
With NetMF and semantic versioning (Major.Minor.Patch.Build), I could install software built with NetMF 4.2 (4.2.x.x) on any 4.2.x.x firmware as the API didn’t change, but for 4.3.x.x I would need to update the firmware.
I’m asking if the same holds for TinyCLR. I realize the patch and build points may fix some problems, but the API won’t have changed so I can still install and run the user code. It is up to me to decide whether the fixes will benefit me or only fix features I don’t actually use.
The point is to only upgrade the firmware out in the field when absolutely necessary, as we are relying on our users working in hostile environments with unreliable power supplies on the far side of the planet, and we really don’t want to risk bricking the device!