<div dir="ltr">HI all,<div><br></div><div>This past week or so i've been dealing with a number of issues relating to a handful of still Qt 5 based projects trying to make use of updated dependencies. These issues have revealed that the level of support for Qt 5 as a platform in general is now subject to a significant degree of bit-rot. As such, we need to set a point at which we consider Qt 5 to no longer be supported.</div><div><br></div><div>To start I would like to remove support for all CD builds (Windows, Appimage, macOS) as well as CI support for Windows. There is already a general view in Craft that Qt 5 is unmaintained and this removal simply reflects that. </div><div><br></div><div>Additionally, several recent attempts to update our Windows Qt 5.15 images, based on MSVC 2019, have all failed due to various different changes (with the build of MPFR breaking for reasons unknown - likely MSys2 updates - and QXMPP failing to build yet again....) which is not a tenable position for a "CI supported" platform.</div><div><br></div><div>That removal is proposed to be essentially immediately (ie. now).</div><div><br></div><div>Subsequent to that I would also like to forbid any further feature releases to be made of Qt 5 software following the end of this calendar year, to clearly signal to the involved developers that they need to work on getting a Qt 6 release out. Patch releases to resolve bugs and security issues could continue to be made for a period of 6 more months at most.</div><div><br></div><div>Any application that does not have a port underway as at the point where feature releases become forbidden is proposed to be archived as unmaintained at that time, with the same fate befalling applications that have an unreleased port branch on 1 July 2025.</div><div><br></div><div>Should at any point post-31 December 2024 there become issues that make Qt 5 CI unsustainable for the remaining platforms (Linux and FreeBSD) then we would discontinue CI for them at that time as well with minimal notice being given in advance.</div><div><br></div><div>Note that while this may seem a little "over the top" it is necessary to reduce the maintenance burden and cost of keeping Qt 5 alive (for an ever decreasing number of applications) on the maintainers of central infrastructure (such as myself). </div><div><br></div><div>Regards,</div><div>Ben</div><div><br></div><div><br></div></div>