From Qt Wiki
Jump to navigation Jump to search

Qt Products Overview

This page is about the final products that the Qt Project (and The Qt Company) release. It is meant as an internal guide for people regularly contribute to Qt. It is probably not relevant for most people. Currently some discussions are ongoing about products and definitions, so this page will be out of date in no time, please help updating it. Below will be a summary how at this point in time the Qt Frameworks aka Qt for Application Development is managed as a product.


At the moment the main definition for what a Qt release is. qt5.git (qt5 from here on) is a git repo living along all Qt modules on . qt5 is complex because it's not well defined which purpose it serves. In the past, Qt was thought to be exactly one product, that has changed with for example the embedded offering, the installer framework and Qt Creator. qt5 is a regular git repository serving several purposes:

  • it contains some helpers that are needed to build Qt on Windows (gnuwin32 subdir)
  • it contains bits of the build system/configure scripts so that they can be run from the top level
  • it contains the init_repo script to help checking out the git submodules it contains
  • it contains git submodules that are the Qt frameworks, some are not released/active
  • it defines a set of sha1s of Qt git modules that are known to work well together (in the sense that they have been compiled against each other and all automated tests passed for all modules)
    • in this capacity it serves contributors to find a state that is guaranteed to work on at least the supported platforms.
  • it is used for releases
    • it contains the final tags and in the top level, so that's what a release is, this is the defining point
  • it is used for continuous integration


For the commercial and open source releases of Qt we produce binary packages. They are the result of running the continuous integration on the qt5 repository and packaging up the binaries that fall out into nice packages that the installer delivers. At the moment Qt Creator has its own rules and does things differently, but we're slowly moving towards having one process for all of this. Click a button, out falls a release.

Continuous Integration

This is the most relevant bit for people working on Qt but not making packages. qt5.git tracks a state of repositories that have all been tested together and found to be good. As much as automated testing can find out about that at least. When a patch for any repository gets merged, it will go into a branch of said repository. The repository is then tested about the current state of qt5. qt5 is _not_ changed.

This means you always work against a stable unchanging baseline. It also means that if you want to update e.g. qtdeclarative to use a newly added API in qtbase, you'll have no way of doing so, unless qt5 changes.

Supermodule updates - how qt5 progresses

Of course we need qt5 to advance with more patches in the modules as often as possible to track the state in the modules. For that the git submodules need to be changed. This is the time where a new set of modules will be tested against each other.

Working with submodules can be hard. For those inside The Qt Company network we created a button in the Coin web interface to do the job for you - create a change that tries to update all qt5.git submodules to the latest and greatest of the corresponding branches. Doing an update manually is also quite possible.

Manual supermodule update

You may want to advance one of the git submodules in qt5. The easiest way is to do a fresh clone of qt5.git and _not_ initialize any of the submodules. Let's update qtdeclarative in the 5.8 branch.

git clone qt5meta
cd qt5meta
git checkout 5.8
git submodule update --init qtdeclarative
cd qtdeclarative
git checkout origin/5.8
cd ..
git add qtdeclarative
git commit -m "Updated qtdeclarative, because Frederik said I should do it"
git push to gerrit (this is up to you to figure out, I assume you know how to set up gerrit if you're doing this)...