[Development] Regarding QML cache strict version compatibility

[Lars Knoll]

> On 5 Mar 2025, at 10:49, Ulf Hermann via Development <development at qt-project.org> wrote:
> 
> 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.

As far as I remember, we put in the strict check simply to be on the safe side. When we released the first versions of the disk cache, the binary format was still in flux, both for the compiled data as well as the byte code. With the check in place, we could fix bugs and improve things much more quickly back then.

Both are a lot more settled these days, so it might make sense to relax that check a bit, maybe remove the check for the patch level as a first step. Of course that has implications as Ulf noted below and will require extra care when doing bug fixes inside a minor version.

Cheers,
Lars

> 
> 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
> -- 
> Development mailing list
> Development at qt-project.org
> https://lists.qt-project.org/listinfo/development