Qt Modules' Maturity Level: The list

Last week, I blogged about the framework of levels we're proposing to use for Qt in the context of Open Governance and future development. I said then that we had also taken the time to look into what code we have in Qt and decide what level it should be in. Today, I'd like to share the list that was the result of that work.

First of all, please understand that this applies to future releases of Qt, most importantly Qt 4.8 and 5.0. Since we never add or remove features to existing and current release series, the framework doesn't apply there, except as in what kind of bugfixes we might be accepting. For example, a bugfix for a corner case could potentially introduce regressions, so the community needs to take into account the quality level of the code and the ability to execute regression and release testing before accepting said commits. Moreover, it's also possible to obtain differentiated support for past releases from other companies, especially from Digia. This is however outside the scope Open Governance.

Second, the list below contains only what is not in states Active or Maintained. We felt that the most important thing to do right now was to be really honest about what we (Nokia) are working on and what we're not working on. This is especially important for people reporting bugs, since it is unlikely that we will fix low-priority issues in subsystems that are in the Done state or lower. What's not on the list below is then under the state "Active" or "Maintained", like for example QtDBus. Also note that this list focuses on Qt only, which is the older codebase, containing more legacy.

This first publishing of the list is, by necessity of a blog, a static list. In reality, when Open Governance and Qt 5 work kick in, this list will be very much dynamic, so I'll be importing it into the Qt Developer Network to be edited and kept up-to-date. So I want to be very clear that the list can change and modules may go up or down in the Level scale. The only things that should not happen are: a) sacrifice quality and b) take Qt in the wrong direction (backwards). As an example of the latter point, functionality that gets Removed from Qt should not be brought back: we don't want to support IRIX, the non-Unicode Windows versions or Microsoft Visual Studio 6.0.

Finally, let me remind you that Done is not Deprecated! Done really means "stability and zero regressions are the most important things, so we are not adding features and we are not working on improving performance, but it's fine to use this code".

The list

Modules

• ActiveQt
  Overall module state: Done
  New Maintainer Required
• Phonon
  Overall module state: Done inside Qt, Maintained outside of Qt
  Reasoning: QtMultimediaKit recommended instead; development of Phonon continues and is maintained outside of Qt, by the KDE community.
• qmake
  Overall module state: Done
  Reasoning: stable code, we don't recommend bringing it up in the level list. Research into a future, more modern buildsystem has started. 
  • XCode integration
    State: Deprecated
    New Maintainer Required.
• Qt Designer
  State: Done
  Reasoning: Qt Quick is recommended for developing UIs from now on, so the new Qt Quick Designer should take over the capabilities of the classic Qt Designer.
• Qt3Support
  Overall module state: Deprecated
  Reasoning: Qt3Support was provided as a porting layer from Qt 3, so the recommendation is to finish the port. Qt3Support will be Removed in Qt 5.
• QtCore
  Overall module state: Active/Maintained 
  • QFileSystemWatcher
    State: Deprecated
    Reasoning: flawed design, a replacement is required. We're open for ideas in that area.
  • Abstract file engines
    State: Deprecated
    Reasoning: flawed design, this is the wrong level to provide a virtual filesystem, so we don't recommend taking this over. In Qt 5, this functionality will be Removed.
• QtDeclarative
  Overall module state: Active/Maintained 
  • Graphics view support (i.e., QML 1.x)
    State: Done
    Reasoning: QML Scene Graph-based QML 2 is recommended and will become available in Qt 5.
• QtGui
  Overall module state: Active/Maintained
  More information about reorganisation of this module, see the Qt 5 blog. 
  • XLFD support for the font system
    State: Deprecated
    Reasoning: this is obsolete functionality in X11 as modern systems use client-side fonts; doesn't affect other platforms.
  • Graphics Effects
    State: Deprecated
    Reasoning: flawed design, we don't recommend taking maintainership of this code.
  • Graphics View
    State: Done
    Reasoning: stable code for which stability and reduced risk of regressions is more important; we don't plan on adding more features.
  • Implicit native child widget
    State: Done
    Reasoning: flawed design, we don't recommend taking maintainership of this code.
    Note: widgets with explicit native window handles, like Direct3D view, will still be supported.
  • Printing support
    State: Done
    New maintainer required. 
    • Postscript support - Deprecated
      Reasoning: obsolete support, PDF is enough nowadays.
  • QPainter
    State: Done
    Reasoning: stable code for which stability and reduced risk of regressions is more important; we don't recommend bringing the maintainership level up. 
    • Raster and OpenGL (ES) 2 engines - Maintained.
    • Other engines - Done and New Maintainer required.
  • QPainterPath's "set" operations
    State: Deprecated
    Reasoning: flawed design, we don't recommend taking maintainership of this code.
  • QPicture
    State: Deprecated
    New maintainer required.
  • QSound
    State: Deprecated
    Reasoning: better solution available in QtMultimediaKit.
  • Styles
    State: Done
    Reasoning: stable code for which stability is extremely important, so we don't recommend bringing the maturity level back up; Qt Quick-based development is expected for the future of UIs and, with it, Qt Quick-based theming and style possibilities. 
    • Motif and CDE styles - Deprecated
      Reasoning: obsolete.
  • Stylesheets
    State: Done
    Reasoning: stable code for which stability is extremely important, so we don't recommend bringing the maturity level back up; Qt Quick-based development is expected for the future of UIs and, with it, Qt Quick-based theming and style possibilities.
  • Widget classes like QPushButton, QLineEdit, etc.
    State: Done
    Reasoning: stable code for which stability and reduced risk of regressions are important, so we don't recommend bringing the maturity level back up; Qt Quick-based development is expected for the future of UIs, with Qt Quick Components.
  • XIM support
    State: Deprecated
    Reasoning: flawed design, we don't recommend taking up maintainership of this code.
• QtNetwork
  Overall module state: Active/Maintained 
  • QHttp and QFtp
    State: Deprecated
    Reasoning: replaced by QNetworkAccessManager; we welcome research supporting the filesystem functionality of FTP that is not currently present in QNetworkAccessManager. In Qt 5, these classes will be Removed.
• QtScript
  Overall module state: Active/Maintained 
  • QScriptEngineAgent and related classes
    State: Deprecated
    Reasoning: flawed design, being replaced by a better design.
• QtSql
  Overall module state: Done
  New maintainer required.
• QtSvg
  Overall module state: Deprecated
  New maintainer required
  Reasoning: SVG Full (as opposed to SVG Tiny) functionality available in QtWebKit, which should be used instead; we welcome research for a replacement for the SVG-generating code.
• QtWebKit
  Overall module state: Active/Maintained 
  • QWebView and QGraphicsWebView
    State: Done
    Reasoning: moved to a separate library in Qt 5, the main entry point for web views will be the Qt Quick-based "webview" component.
• QtXml
  Overall module state: Done
  Reasoning: QXmlStreamReader and QXmlStreamWriter are recommended instead and are located in the QtCore module.
• QtXmlPatterns
  Overall module state: Done
  New maintainer required.

Functionality

• Carbon support in Mac OS X
  State: Done
  Reasoning: Cocoa support is available and Carbon cannot be used to create 64-bit applications. We'd like eventually to Deprecate and even Remove this functionality during the Qt 5 lifecycle, as this code is currently a maintenance burden (like Windows non-Unicode was).
• HP-UX, AIX and Solaris support
  State: Done
  New maintainer required.
• Old Qt solutions archive
  State: Deprecated
  Reasoning: old code, not maintained anymore.
• Bearer Management inside Qt Mobility
  State: Deprecated for now, will probably be Removed in Qt 5.
  Reasoning: the copy of the code maintained in QtNetwork is the recommended interface.
• Qt Multimedia inside Qt
  State: for 4.8 it is Deprecated, in Qt 5 it is replaced by the Qt MultimediaKit copy with the modularisation of Qt.
• Phonon copy inside Qt
  State: Done
  Reasoning: a separate release of Phonon, with its own version numbers, is available and can be used instead; the copy inside Qt will not be updated further.
• Qt WebKit copy inside Qt
  State: Deprecated
  Reasoning: a separate QtWebKit release, with its own version numbers, is available and should be used instead with Qt 4.7 and 4.8, for those looking for updates. In Qt 5, the separate release is reintegrated through the Qt modularisation.
• QWS (a.k.a. the current Qt for Embedded Linux)
  State: Done for Qt 4.8
  Reasoning: the new Lighthouse-based architecture is recommended for new features and new platforms.
• Static builds of examples and demos
  State: Removed
  Reasoning: this is not maintained or checked and the Qt binary builds are always dynamic. Static builds aren't required for reading the source code and learning Qt, they are never deployed to devices.
• Static builds on Mac, Windows and Embedded Linux
  State: Done
• Windows CE port
  State: Done
  New maintainer required.
• WINSCW port
  State: Done
  Reasoning: old and buggy compiler, required only for Symbian simulator builds, should be replaced with a new technology once that is available.

Changing the list

As I said before, this list should live in the Qt Developer Network wiki, where it will be updated as the states change. So how do they change?

The state of a given functionality or module is the choice of the maintainer of that code, who is the ultimate responsible for the quality. So the decision on whether new features and the extent of what other kinds of changes should be accepted or not is also the responsibility of this person. Therefore, to change the state, you have to either convince the current maintainer or become a maintainer yourself.

In that light, we have been discussing with current contributors to Qt and asking them whether they would like to volunteer for maintainership of anything. Digia has already volunteered find someone to maintain the AIX and Solaris ports and KDAB has done the same for Windows CE. Becoming a maintainer for something inside Qt shouldn't be too hard: it takes time and dedication, because it comes with a responsibility. (For that reason, we'd like people to prove that they can do it first, such as by maintaining a branch first)

More discussions on this should begin with Open Governance and the Qt contributors Summit.