Qt公司CTO兼Qt項目的首席維護者（Chief Maintainer）Lars Knoll在Akademy 2019會議上宣布Qt 6計劃於2020年11月發布。在確認這一消息後，KDE項目的開發者就關於下一代框架所採用的工具包更新進行了早期討論。KDE項目開發者Volker Krause和大家分享了一些他對KDE 6的想法，以及團隊討論的內容。

Volker 表示KDE Frameworks 6 會在Qt 6.0 推出的兩年內，或至少一年後發布。因為 Qt 6.0 已被確定時，KDE Frameworks 6 的實際開發工作大概會從2020 年下半年開始。而且在不久的將來，在開發的某個階段中，他們有可能會採用敏捷開發中的“較短工作週期”（Scrum Sprint）方式。

雖然Qt 團隊一直表示會將盡最大努力保持Qt 5 和Qt 6 之間的兼容性，但新的主要版本肯定也會觸發KDE 的更改。為此，KDE 團隊也會提前做好準備。

KDE 團隊會將代碼從已棄用的Qt 方法中移植出去，以便在禁用棄用方法的情況下從Qt 5.14 開始完全構建。這部分的主要工作是關於刪除已棄用的模塊、類或方法的使用，這些模塊、類或方法預期將隨 Qt 6 或KF6 的發布而一起消失。

另外，還有一些依賴Qt 6 或需要執行實際ABI 中斷的任務，不過這些任務​​在目前尚屬少數，而且當然需要等到開發的那個階段才開始（大概是在2020 年下半年）。

除了計劃要在KF6 中實現的目標外，對如何過渡到KF6 的計劃也同樣重要。Lars 提出了Qt 採用的方法，但KDE 的情況在某些方面與Qt 不同。KDE 並不是主要生產框架，而是在這些框架的基礎上構建產品（Plasma 和數百個應用程序），這使我們能夠為允許更改或刪除的內容定義其他標準。

KDE團隊的想法是定義一組阻止重大更改的模塊。也就是說，在進行重大更改之前，需要對這些模塊進行調整（或者至少需要微調）。例如避免類似“ KHTML已被棄用，請移植到QWebEngine”之類的事情。雖然兩者都可以以某種方式渲染HTML文檔，但這就是不同之處，API和API的功能有很大的不同，並且並非所有的用例都可以輕鬆映射（如果有的話）。更重要的是，解決這一問題的負擔不應僅由應用程序維護人員承擔，因為這將導致許多事情在未來幾年內仍留在Qt5/KF5上。

最後，KDE 團隊已經開始了一些比較底層的工作，例如由 Friedrich 牽頭負責的基礎結構研究工作，以在編譯時禁用KDE Framework 中不推薦使用的方法，這個做法與Qt 類似。

Andreas 已將Step、Kalzium 和Parley 從KHTML 移植出去，而Sune 已開始為KHelpCenter 做同樣的事情。在Konqueror 中，他們還擺脫了KHTML 的大量使用，現在僅保留about 頁面還使用KHTML。