QtCS2024 Breaking The Monolith

From Qt Wiki
Revision as of 10:09, 6 September 2024 by Thiago Macieira (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
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