Announcement

Collapse
No announcement yet.

With Qt 5 Being Talked About, So Is KDE 5

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • With Qt 5 Being Talked About, So Is KDE 5

    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...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    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?

    Comment


    • #3
      Originally posted by sirdilznik View Post
      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.

      Comment


      • #4
        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.


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

        Comment


        • #5
          Originally posted by panda84 View Post
          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.

          Comment


          • #6
            Originally posted by TheBlackCat View Post
            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.

            Comment


            • #7
              Originally posted by loonyphoenix View Post
              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.

              Comment


              • #8

                After my last blog about a possible future KDE Platform 5 due to Qt 5, it was interesting to watch the number of "Oh no, not another big rel...

                Comment

                Working...
                X