Qt 6.0 RC1 Takes Flight - Qt 6.0 Should Be Here By Mid-December

[phoronix]

Phoronix: Qt 6.0 RC1 Takes Flight - Qt 6.0 Should Be Here By Mid-December

The Qt Company has just announced Qt 6.0 Release Candidate 1 as what should be the second to the last test build ahead of the big Qt 6.0 toolkit release next month...

http://www.phoronix.com/scan.php?pag...se-Candidate-1

[timofonic]

Will it be buggier than Qt 5.x? I hope not...

[bug77]

Will it be buggier than Qt 5.x? I hope not...

It's supposed to be mostly about cleanup and stabilization, so let's hope not. But more troublesome modules have been temporarily removed, so it also won't be complete for a while (I don't know of a timeline for getting back to feature parity).

[sheldonl]

Anyone know what this means for KDE? In the past major version releases of QT have resulted in lengthy porting efforts with lots of breakage in kdelibs, resulting in source and binary API breakage to applications. Based on bug77 's comment I'm hoping that QT6 will have minimal API breakage. Anyone know if it will remain source and binary compatible?

[Vistaus]

Anyone know what this means for KDE? In the past major version releases of QT have resulted in lengthy porting efforts with lots of breakage in kdelibs, resulting in source and binary API breakage to applications. Based on bug77 's comment I'm hoping that QT6 will have minimal API breakage. Anyone know if it will remain source and binary compatible?

Better question is if KDE Plasma will follow suit with version numbers again. In the past, they followed Qt's version numbering, i.e. KDE 3 = Qt 3, KDE 4 = Qt 4 and KDE Plasma 5 = Qt 5. So does Qt 6 mean KDE Plasma 6?

[Awesomeness]

Better question is if KDE Plasma will follow suit with version numbers again. In the past, they followed Qt's version numbering, i.e. KDE 3 = Qt 3, KDE 4 = Qt 4 and KDE Plasma 5 = Qt 5. So does Qt 6 mean KDE Plasma 6?

KF6 first, though.

[bug77]

Anyone know what this means for KDE? In the past major version releases of QT have resulted in lengthy porting efforts with lots of breakage in kdelibs, resulting in source and binary API breakage to applications. Based on bug77 's comment I'm hoping that QT6 will have minimal API breakage. Anyone know if it will remain source and binary compatible?

I don't think binary compatibility between major versions will happen. As non-disruptive as this release is supposed to be, simply removing deprecated stuff prevents older binaries from working.
As for what this means for KDE... probably not much at the moment. The whole team barely copes with adding support for Wayland+Qt5. If Qt6 doesn't simplify that dramatically, my guess is they'll do what they did with Wayland: sit it out until in matures significantly.

[JackLilhammers]

I don't really see a big problem here. If I were in the Kde devs I'd avoid Qt 6 for the first year.
The only significant drawback is that the QtCo restricted access to Qt 5.15, but maybe they can backport the things they really need

[carewolf]

I don't really see a big problem here. If I were in the Kde devs I'd avoid Qt 6 for the first year.
The only significant drawback is that the QtCo restricted access to Qt 5.15, but maybe they can backport the things they really need

I would advise most people that. Qt 6.0 is a basis to try to start porting, but probably a bit rough around the edges and missing pieces.

[bug77]

I don't really see a big problem here. If I were in the Kde devs I'd avoid Qt 6 for the first year.
The only significant drawback is that the QtCo restricted access to Qt 5.15, but maybe they can backport the things they really need

That's not ideal either. It means you won't have anything ready to ship for 2 years from now. You'd normally start working on porting right away, in a separate branch, report bugs and add more stuff as things get added back to Qt. But like I said, there aren't enough people working on the project to do that.