bug: venusqm CIQ version isn't updated

In the other thread, a CIQ team member also pointed out that device files used to be distributed with the SDK, so you could easily go back to the old devices by using the old SDK.

They switched to the current method because they ended up having to release minor versions of the SDK just because devices were updated.

Details:

- app already has compile-time has check for CIQ 4.2 feature X and uses feature X

(this time I used CIQ 4.2 because I don't want to talk about the VERY latest CIQ version). [I don't care if there's actually any CIQ 4.2-specific features, it's just a fake example. I could make a real example out of this with more effort, but I'm already putting a lot of effort into this comment]

- when app was previously built a year ago, old device file had firmware version 18.10 (fake example) with CIQ version 4.2.0, and I built with SDK 6.4.2

- today, new device file has firmware version 22.20 (another fake example) with CIQ version 5.1.0, which requires SDK 8.1.0

- I as a dev don't want to build with SDK 8.1.0, I want to build with SDK 6.4.2

- So I edit the device file so firmwareVersion is 17.10 because I FORGOT what firmware version was in the old device, but I change connectIqVersion to 4.2.0. (Yes, I realize I could just look in the old IQ file's manifest.xml to get the correct versions, but maybe I don't have it anymore)

- In this fake example, the device's firmware version 17.10 has a CIQ version of 4.1.0

- I build my app and somebody with firmware version 17.10 and CIQ version 4.1.0 installs it

- They run the app and it crashes because the compile time has check for feature X returned true, and the app tries to use feature X but the device does not have feature X

> When your source code doesn't change at all, what is the reason that compilation with the new sdk limit the watches by them firmware? 

It's because you're building with the new device files and the new device files guarantee new firmware / new CIQ version because the CIQ team assumes new devs want the newer CIQ. Run-time version checks and has checks only go so far, at some point devs will want users to have new firmware / CIQ features.

Yes, you suggested that a better way to do this would be to use minApiVersion to force users to upgrade firmware, but obviously the CIQ team did not decide to go in that direction.

As far as old device files go, as discussed in the other thread, the CIQ team (or at least one member) recognizes that devs may want to use old device files and old SDK.

> Of course you are right on condition you add something to source code or something is deleted from API with the new firmware.

No my point was that:

- Kyle.ConnectIQ was right that manually editing the device files can cause a crash

and

- it has nothing to do with: "if app can crash just before I rebuild it without any changes in source code it means new firmware can have not only API but also duplicated api (for app built the older SDK and the newest). Or upgrading of firmware upgrading installed app to the newest CIQ."

--

Again, simple example:

TL;DR I change firmwareVersion to older version, but I don't change connectIqVersion to the correct value for that firmware. I have a compile-time has check which returns true for feature X, but the app is installed on a device which does not have X, so the app crashes

Of course you are right on condition you add something to source code or something is deleted from API with the new firmware.

When your source code doesn't change at all, what is the reason that compilation with the new sdk limit the watches by them firmware? 

Example (false data)

2022-02 F7 in market 2022'01, firmware 13.12 sdk 3.4, app tested and build for f7

2025-03 f7 firmware 20.22 (the same in *.json), sdk 8.1, the same source code (I don't use any new features above sdk 3.4)  - and only user who has 20.22 can download app. Why?

I Rrestore devices form 2022-02, add some code and build with sdk 3.4 for the  f7 with minimal version of 13.12. Putting app in to the store for every user of f7. Possible? Yes, so why can't do the same with sdk 8.1? 

Every developer have to do something if he wants to support a different device (jungle, has), the same is with the different firmware. I don't care about version of firmware, for me important is CIQ version or rather minimal sdk I put into manifest. 

So limiting devices by firmware version means - the current firmware is not compatible with the minimal version of sdk - and isn't the truth just because I use my own apps in beta version build months/years ago.

Using the new sdk is obligatory if you want to support the newest devices (not firmware) because the old one doesn't know the new devices.

Of course, the solution is to modify each json and change the version

If app can crash just before I rebuild it without any changes in source code it means new firmware can have not only API but also duplicated api (for app built the older SDK and the newest). Or upgrading of firmware upgrading installed app to the newest CIQ.

Sorry to address this real late but I can easily think of a scenario where editing compiler.json will crash the device without either of the above statements in bold being true.

Quite simply, if you edit compiler.json to allow an app to be installed on a device with older firmware, it runs the risk of invalidating compile-time API has checks which would normally prevent an app from crashing when you try to use an API feature that isn't present. This will happen if you change firmwareVersion to an older firmware without also changing connectIqVersion to the corresponding CIQ version for the older firmware.

--

Details:

For example, right now fr955/compiler.json has the following versions for its only part number:

"connectIQVersion": "5.1.0",
"firmwareVersion": 2222,

This means that if I build an app for fr955, the minimum firmware to install the app on fr955 is 22.22, and the device is guaranteed to have at least 5.1.0.

Now let's say I change firmwareVersion to something like 1918, but I don't change connectIqVersion. Now the app can be installed on devices that have CIQ < 5.1.0. Maybe CIQ 5.0 or even 4.x.

Let's also say that I have optimization on, but I don't use the --disable-api-has-check-removal compiler flag.

And let's say my app uses Toybox.Notifications (new for 5.1.0), and uses a has check like Toybox has :Notifications before accessing Toybox.Notifications.*. The has check will be resolved at compile-time, but how?

I tried to answer this question by looking at the value of Toybox has :Notifications in the simulator, with optimization set to the highest level and without --disable-api-has-check-removal (although it shouldn't matter for the sim, since presumably the sim and the compiler have the same idea of the capabilities for a given device).

- fr945 (CIQ 3.x): Toybox has :Notifications == false (of course)

- fr955 (CIQ 5.1.0, unedited device file): Toybox has :Notifications == true (of course)

- fr955 (compiler.json edited to change firmwareVersion to something less than 2222 (e.g. 1918))\: Toybox has :Notifications == true (as expected)

- fr955 (compiler.json edited to change connectIqVersion to 5.0.0): Toybox has :Notifications == false (as expected)

--

The problem I mentioned above doesn't just have to apply to the *latest* API features. What if I backdate firmwareVersion to some firmware which only supports CIQ 4.1, but I accidentally change ciqVersion to "4.2.0"? Now if my app uses a compile-time has check for a CIQ 4.2.0-only feature, the check will be true and the app could crash at runtime because it doesn't really have that feature.

If you backdate firmwareVersion manually, how will you know what version to use? And how will you know the corresponding connectIqVersion to set? Will you search all the device forums to look for a suitable firmware version? Of course the official changelogs don't say what the CIQ version is - if you're lucky, maybe some dedicated user will have a thread with that info.

It seems that instead of editing compiler.json by hand, the real solution is to restore it from a backup, or ideally, have Garmin officially distribute old device files (as discussed in a couple of other threads.)