Qt6 Enabling API Changes
Jump to navigation
Jump to search
- Do nothing / today / qt5.git
- Heads: use the latest revision of each branch (the system we used to have in the past)
- Modules containing pinned dependency sha1s
- Monolithic repository for essentials
- A way to stage breaking changes across modules (updating for example qtbase, qtdeclarative and qt5.git at the same time)
Option 3:
Each module is completely self-contained, that means qt5 is not required as such (but may still exist as a collection of all modules)
In each module we have a list of dependencies and their sha1:
qtdeclarative depends on qtbase and svg, could for example declare:
[requirements]
qt/qtbase 1234fffabcde
qt/qtsvg fffffffff
Updates for a release (and also otherwise) must happen regularly (e.g. nightly), moving each module forward towards newer dependencies, this would be implemented as bot which updates the above mentioned requirements file.
Option 4:
Merging at least qtbase and qtdeclarative and probably a whole lot more into one repository. Likely excluding webengine and webkit.
Option 5:
Presumably do some annotation of the commit message in Gerrit, or figure out how to connect changes in Gerrit in another way.
https://bugreports.qt.io/browse/QTQAINFRA-868 is related; the suggestion is essentially that all staged changes are implicitly integrated atomically.
OpenStack's Zuul has a somewhat elaborate system to make it explicit.
| Requirements | 1 today | 2 heads | 3 modules with dependency pinning | 4 monolithic repo | 5 cross-module staging |
|---|---|---|---|---|---|
| API changes (across modules) | hard and slow | easy, resource heavy | yes | yes | yes, but it's still possible to block qt5.git |
| All modules should always work (build+test) | yes | no | yes | yes | yes |
| Simple (contributors should understand from the outside) | confusing (needs knowledge of qt5.git) | yes | transparent but not super simple | yes, from a git perspective it's easy, but testing will need added complexity to be efficient | depends on how we write the UI, could need Gerrit changes |
| Ideally the same for Qt 5 and 6 (and 7...?) | we don't want to continue with this, so no | no | yes | mostly yes | |
| Easy to implement | yes | yes | needs tooling and visualization to allow us to know which modules are behind | yes | yes, if the easy route is taken. otherwise needs sync points across modules, may need good UI which is hard (extending Gerrit or Coin) |
| Amount of work | none | little | lots | git history grafting, cherry-picking is hard later, testing needs optimizing | |
| Merges between Qt 5 and 6 | easy | easy | easy | hard | easy |
| Release/Snapshot build | Clear: Content is build at once and all leafs are based on same essential components | Easier: Newest changes are always in use (also in submodule builds and so on possible compilation issues are seen already in submodule integration phase) | Hopefully easier "qt5.git updates" because it's incremental. Depends a lot on good visualization and requires work. | Easier | Easier |