QtCS2024 Breaking The Monolith
Jump to navigation
Jump to search
Notes
- Should we split qtbase even further than it is? Core separate from Gui
- Should add-on modules support require only the last Qt LTS?
- Whatever we do, we shouldn't lose our consistency in quality
- Compiler, platform requirements, C++ level, etc.
- Danger: incompatible versions, if "max versions" exist
- Danger: fragmentation of contributors' attentions
- Right now, we are "all in" for every release and we are all invested in all modules' quality
Bring back Qt Solutions - source-only releases
- Source-compatibility only and mostly
- Should be easy to integrate into existing projects (used to be just a .pri file, for qmake)
- Issue is discoverability - Qt Market Place?
Installation and packaging
- Maintanance tool should support installing things
- But shouldn't make things more confusing!
- Different version numbers going out-of-sync would be confusing
- C++ doesn't have a good way outside of this, which makes things difficult for users
- This needs to be investigated first
Look at what the KDE Frameworks split and how the process went, pros and cons
- Splitting too-fine-grained has a drawbacks, for users who need more than just a few
- Dependencies become non-obvious
- Left-over modules that become dumping ground because they weren't cleaned up
- All modules still released in-sync
Use of private API is extensive in Qt between libraries
- Too convenient, also difficult to change now without BC break
- Intra-module dependencies may be OK, inter-module ones with different release cycles are not
- Create an intermediate class between public and private API ("protected" API)
- Not as well documented
- Documented as meta-stable: stable for only a period of time, but may change beyond that
Is it fine right now?
- Runtime dependencies are mostly ok already (no deploying of QtWidgets in Android apps for example)
- Splitting further out or having different release cycles may be counter-productive
- Does allow us to immediately use new APIs in all modules
- No waiting for the new content to have been present in the last LTS
- But isn't this what stable user applications already face?
- But may be required for some modules, for other reasons
- qtwebengine is an example
Use the feature system more
- Allow depopulating some libraries for constrained systems