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。