Version Numbers and IFU

Currently moving my app from NetMF to TinyClr.

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.

The version is 2.2.0.51. Two last numbers are always 00 for user, these numbers are used internally.

@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?

Hi,

“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!

@Dat_Tran
Following up on this as there has been a new release!
If the version number sequence is:

2.2.0.4xxx
2.2.0.5xxx
2.2.0.6xxx

2.2.0.9xxx

should I expect the next version number in the sequence to be
2.2.0.10xxx, 2.2.0.Axxx or 2.2.1.0xxx ?

(I’m assuming any change to the xxx part of the number doesn’t require loading new firmware as the API hasn’t changed.)

I think 0.9 then 1.0

1 Like

Hi, is there any way to read the TinyCLR version for which an app has been compiled? After loading the application, I can get the application version using:
string appVersion = updater.VerifyApplication();

But if the “.tca” application has been compiled for a newer version of the TinyCLR, I want to ensure that the correct “.ghi” firmware is also available to be loaded along with the application before calling the “updater.FlashAndReset();” function.

Otherwise, I need to add the firmware version to the the file name as C_born did.
This can be risky if the user renames the file. Having the chance to extract the target TinyCLR version from the .tca file would be great.
Doing this I can check if the .tca application being loaded matches the current version of the firmware loaded on the SOM or check if the correct .ghi file is also provided to be loaded concurrently.

Thank you,
Vittorio

We are not sure what you mean.

and you already know how to get the app version

Taking about the firmware?

You can add 512, 1024 bytes or something to the front or the end of GHI firmware. Your application will check it, parse it, remove it before passing the actual firmware to IFU, so no worry about your customer change the filename. Add crc if you want.

If your customer is going to open the file, edit content, ask them don’t do that :).

Thank you. Yes, I was talking about the firmware for which the TCA was compiled. I was just checking if there was a way to get the version of the target framework of the TCA file directly from the file itself, as it should be present somewhere in it. But ok, adding a block to either side of the file is a possible approach.
Best, Vittorio