QML cache gets stale too easily

Status changed to 'Confirmed' because the bug affects multiple users.

1) for package related upgrades, this is a developer only problem since QML cache is cleared on image updates
2) for app updates, the question is critically relevant right now so it should be double-checked more quickly than trying to address the developer problem

(my guess / vague memory is that app upgrades are also already handled similar to image upgrades, but it's better to check)

It really depends on exactly what the problem scenario is. Currently, whenever *any* QML file changes, the whole cache is dropped and rebuilt. This includes SDK and base QML deps, not only files shipped by the app itself.

The only case where it is currently not rebuilt is when a provider library changes its QML bindings ABI. For this we are looking into ways to encode library versions on the magic headers of the cache file, although for now considering libraries are only updated on image upgrade, the cache should ensure validity. The only breaking case is when the developer pushes a new QML plugin with different ABI than what the cache was built against.

So I guess the question is:

What was the scenario/issue that happened which lead to this bug?

Yeah, we've used an updated set of plugins from a PPA for testing, didn't clean the cache and unity8 as crashing some 30% of the time on startup...

Disabling cache altogether when image writable would be good enough for our case. But then it would mean we're not testing the real thing and could miss issues that would only crop up once cache is enabled again?

Yeah, while disabling cache when the image is writable is a useful workaround, that could have the bad side effect you described, so probably better to not disable it for now.

Proper fix would be improve the way it encodes library versions and magic header, like ricmm described.