[Development] Regarding QML cache strict version compatibility

Ulf Hermann ulf.hermann at qt.io
Wed Mar 5 10:49:10 CET 2025


Hi,

> According to `Unit::verifyHeader()` @ `qv4compileddata.cpp`, the version 
> needs to strictly match:

This is a thorny issue. The Qt version check was put in along with a 
number of other checks back when they invented the QML disk cache. There 
was no detailed reasoning for the individual checks and I cannot recover 
the motivation from either Jira, gerrit, or the git log. If you can help 
there, please speak up.

I would really like to get rid of the whole Qt version check, but this 
may have far reaching consequences, good and bad.

Indeed the code checks for the data structure version before checking 
for the Qt version. Whenever we change something incompatible about the 
compilation units we're suppposed to bump the data structure version, 
invalidating all existing cache files.

The data structure version has been at 0x42 since Qt 6.8.0. Removing the 
check would claim that all artifacts produced by qmlcachegen of Qt 6.8.0 
or newer are compatible with any Qt version up to current dev.

In fact I can't think of any actual reason why they wouldn't be. The 
main hurdle in the past were the methods in 
QQmlPrivate::AOTCompiledContext which are called from the generated C++ 
code. Those are not formally public API, but since old binaries won't 
load if we change them in an incompatible way, they have been binary 
compatible in reality. This includes keeping old versions of the methods 
around in compat/removed_api.cpp, so they should even be 
behavior-compatible.

But here's the problem: Due to the version check, no one can test this. 
Consequently, we have probably put in some bugs that make the QML cache 
incompatible in practice. Bugs that result from incompatible byte code 
being loaded are particularly evasive since they produce meaningless 
stack traces and disappear on re-compilation. I'm not very fond of 
giving myself such headaches.

So I would rather not remove the check in 6.8. I can provide an 
environment variable that causes the check to be skipped and you can use 
that at your own risk, though. Since the data structure version changed 
between 6.7 and 6.8, skipping the check completely on 6.8 is the same as 
ignoring only the patch version.

I might remove the check unconditionally in 6.10, though (and 
deliberately bump the data structure version before doing so).

The output of qmlcachegen is not backward compatible with older Qt 
versions, but that's generally the case with code compiled against Qt, 
also C++ code. We had this discussion about forward and backward 
compatibility in patch releases in 2023 and at least 
https://wiki.qt.io/Two-way_BC_in_Patch_Releases looks like we were 
dropping forward compatibility. If there's anything more to be said 
about it, please also speak up about that.

best regards,
Ulf


More information about the Development mailing list