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。
