Qt 6.6 status:
* Qt 6.6.2 preparations to be started
* Target is to start branching from '6.6' to '6.6.2' at the beginning of
next week
* Target is to release Qt 6.6.2 by the end of January 2024
Qt 6.7 status:
* Qt 6.7 Beta1 released
* Target is to release Qt 6.7 Beta2
“When we get qmltc and qmlcachegen into a shape where the code generated
by qmltc can directly call the functions and expressions compiled by
qmlcachegen we won't need much of an engine anymore if you exclusively
run pre-compiled code. “ - Ulf
I very much can’t wait for this as I have run into
Hi, have you considered how you can keep compatibility, by making this
change either opt-in or opt-out? Since it seems the refactoring is
already done, it feels like you are making a bet that only has a
negative outcome for those porting/trying to keep up. Good for
maintenance, bad for
Hi, I don’t necessarily want to walk into the specifics of that feature of this
change - more that I think compatibility is something that should be considered
very valuable - to the point that prior to starting work on refactorings that
break compatibility (in behavior in this case), there
On 09/01/2024 10:49, Ulf Hermann via Development wrote:
So, to clarify this some more ... If:
1. you use_multiple_ QML engines in the same process at the same time,
2. you have_different_ import paths, plugin paths, URL interceptors or
network access managers for those engines,
3. you rely on
So, to clarify this some more ... If:
1. you use _multiple_ QML engines in the same process at the same time,
2. you have _different_ import paths, plugin paths, URL interceptors or
network access managers for those engines,
3. you rely on those engines to produce _different results_ for the
Hey,
Thanks Bogdan for all the work on the Android port over the years, and I
appreciate you all for your trust.
Regards,
Assam
On Jan 8, 2024, at 11:52 AM, Axel Spoerl via Development
wrote:
+1 for Assam - it's great working with you!
Von: Development im
