QtCS2024 Breaking The Monolith: Difference between revisions
Jump to navigation
Jump to search
(Created page with "==Notes== * Should we split qtbase even further than it is? Core separate from Gui * Maintanance tool should support installing things ** But shouldn't make things more confusing! ** Different version numbers going out-of-sync would be confusing * Should add-on modules support require only the last Qt LTS? 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 fi...") |
No edit summary |
||
Line 1: | Line 1: | ||
==Notes== | ==Notes== | ||
* Should we split qtbase even further than it is? Core separate from Gui | * Should we split qtbase even further than it is? Core separate from Gui | ||
* Should add-on modules support require only the last Qt LTS? | * 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 | Bring back Qt Solutions - source-only releases | ||
Line 11: | Line 12: | ||
* Should be easy to integrate into existing projects (used to be just a .pri file, for qmake) | * Should be easy to integrate into existing projects (used to be just a .pri file, for qmake) | ||
* Issue is discoverability - Qt Market Place? | * 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 | Look at what the KDE Frameworks split and how the process went, pros and cons | ||
Line 33: | Line 41: | ||
* But may be required for some modules, for other reasons | * But may be required for some modules, for other reasons | ||
** qtwebengine is an example | ** qtwebengine is an example | ||
Use the feature system more | |||
* Allow depopulating some libraries for constrained systems |
Latest revision as of 10:09, 6 September 2024
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