With Qt 5 Being Talked About, So Is KDE 5

[phoronix]

Phoronix: With Qt 5 Being Talked About, So Is KDE 5

Yesterday I delivered the live news about Nokia's plans for Qt 5 with its new features and a road-map to deliver this new tool-kit in the 2012 calendar year. With Qt 5 now being talked about, so is KDE 5...

http://www.phoronix.com/vr.php?view=OTQyOQ

[sirdilznik]

In b4 the GNOME/KDE flame war.

Just so I understand correctly, they're essentially thinking about going with KDE 5.0.x rather than KDE 4.8.x or 4.9.x in an effort to stay consistent with the Qt version numbers even though the changes in KDE will probably be minor enough as to not really warrant a major version number change?

[panda84]

In b4 the GNOME/KDE flame war.

Just so I understand correctly, they're essentially thinking about going with KDE 5.0.x rather than KDE 4.8.x or 4.9.x in an effort to stay consistent with the Qt version numbers even though the changes in KDE will probably be minor enough as to not really warrant a major version number change?

No, if Qt breaks API, then KDE should break API too, because it's a superset of Qt. However KDE is not forced to switch to Qt5 until Qt4 is supported so this time they have "plenty of time to switch to a new version of Qt that is not so different from the previous".
So when they break API (even if it's not a major breakage) they change major number. A minor change happened also between KDE 2 and 3, there's nothing bad.

However KDE 4.8 will for sure land, KDE 4.7 is planned for July 2011, 4.8 for January 2012; Qt 5 will not be ready then. If they want they can keep going with Qt4 until they're comfortable with the switch.

The numbering is different to GNOME which tends to deprecate and then break API even among the same major version.

[panda84]

From KDE core devel:

> > - Can we realistically pull off a minimal migration in time for the
> > planned
> > release date?
>
> i think it is possible, but we don't need to roll out KDE Platform 5 when Qt
> 5 is released, either. in fact, it might be wise to lag by a release to
> allow Qt 5 to settle in a bit and so we aren't chasing Qt's tail during the
> Qt5 development cycle.

Suggestion: target release in Jan 2013, which is also 5 years after the
release of 4.0.

Provided Qt 5.0 does release mid-2012.

http://lists.kde.org/?l=kde-core-dev...1650214043&w=2

So:

• KDE 4.8 - January 2012
• KDE 4.9 - July 2012
• KDE 4.10 = 5.0? - January 2013

[TheBlackCat]

No, if Qt breaks API, then KDE should break API too, because it's a superset of Qt. However KDE is not forced to switch to Qt5 until Qt4 is supported so this time they have "plenty of time to switch to a new version of Qt that is not so different from the previous".
So when they break API (even if it's not a major breakage) they change major number. A minor change happened also between KDE 2 and 3, there's nothing bad.

Technically, it isn't breaking API, it is breaking ABI. Programs compiled against an earlier version of KDE 4.x or Qt 4.x should work with later versions. With a binary compatibility break, they may have to be recompiled. API changes happen fairly often in KDE, and do not necessarily imply a break in binary compatibility. Only binary-incompatible changes are forbidden in point releases.

But if I am reading Aaron's post correctly the Qt 5.x changes will mean that KDE 4.x applications compiled using Qt 4.x will not be binary compatible with KDE 4.x applications compiled using Qt 5.x, even if KDE is otherwise unchanged, so binary compatibility will have to be broken no matter what KDE does. KDE developers may use this opportunity to clean out some cruft and some issues in their API that they can't do without breaking binary compatibility.

[loonyphoenix]

Technically, it isn't breaking API, it is breaking ABI. Programs compiled against an earlier version of KDE 4.x or Qt 4.x should work with later versions. With a binary compatibility break, they may have to be recompiled. API changes happen fairly often in KDE, and do not necessarily imply a break in binary compatibility. Only binary-incompatible changes are forbidden in point releases.

It IS breaking the API, albeit only a little. From the Qt 5 plans post:

To be explicit here – we believe we can keep source compatibility for the majority of cases, but we believe that breaking binary compatibility is needed.

I'm thinking "for the majority of cases" implies there is a minority for which source compatibility WILL break.

[TheBlackCat]

It IS breaking the API, albeit only a little.

Perhaps I wasn't clear. Yes, there will be API changes. But API changes are not the reason for a change from KDE SC 4 to KDE SC 5. In point releases (KDE SC x.x) they are allowed to change the API as long as the ABI does not change. Changing a major release, though (KDE SC x) implies a break in binary compatibility.

This also implies some changes in the API, usually changes that are not possible while maintaining binary compatibility. However, under KDE SC version number rules the important issue is binary compatibility, not API compatibility.

[panda84]

http://techbase.kde.org/Policies/Bin...ssues_With_C++
http://aseigo.blogspot.com/2011/05/relax.html