Qt 5.15 vs 6.x for MuseScore 4.x development
- We are tracking various OS and Qt versions against MuseScore versions at Developer's handbook - Versions Reference, including a section for Macs (by year of release) and maximum macOS version) . All of the below are deduced / referenced from tables from this page.
- What will become MuseScore 4.0 is currently being developed with Qt 5.15.
- MuseScore (4.x) on Qt 5.15 already drops support for MacOS 10.10, 10.11 & 10.12 (compared to what MuseScore 3.6.2 on Qt 5.9 supported. It does not drop any Windows versions when compared with MuseScore 3.6.2 on Qt 5.9.
- There is mention of switching development to Qt 6.x, as per
- As per the Qt Roadmap for 2021, QT 6.2 is expected to be the first Qt 6.x Long Term Support version, and expected in September 2021.
MuseScore (4.x) on Qt 6.0/6.1 would drop support for MacOS 10.13 as well. However, more importantly, it only supports Windows 10 64-bit, e.g. it would be dropping support for
- Windows 7, 8 (32-bit and 64-bit)
- Windows 10 (32-bit)
- Also, not having a 32-bit binary would also impact PortableApps.com, which has a strong preference for the 32-bit binary (which is more universal, because it runs on 64-bit Windows as well)
Question: Should we switch to QT 6.x as soon as possible, e.g. before releasing MuseScore 4, or only on a subsequent minor release (MuseScore 4.1, 4.2, etc.)?
The argument for delaying the switch to Qt 6.x:
- There are a lot of Windows PCs and pre-2012 Macs and which would be stranded if the switch to a later Qt version were to happen sooner rather than later.
- The effort to port from Qt 5.15 to 6.x (?)
- Waiting for Qt 6.2 LTS to be released and stabilised.
The argument for switching to Qt 6.x sooner rather than later
- Support for Qt 5.15 will end before Qt 6.2.
- Avoid confusion by having a minor release drop support for operating systems - With MuseScore versions 1, 2 and 3, everything that was supported with the first release of a major version (1.0, 2.0, 3.0) continued to be supported for the minor releases, 1.3, 2.3, 3.6), since the Qt version did not change mid-major version.
My personal opinion (as a community member, not a developer - I don't have the full picture, nor am I aware of the development impact of delaying) would be
- To delay as long as possible and manage the communication (and possible confusion) as best as possible, to be as inclusive as possible. For example, even if we end up releasing a 4.0.x which is reasonably stable to all these legacy operating systems, before the work on 4.1 (which breaks the compatibility), begins. it may be preferable than having those legacy operating systems stuck on MuseScore 3.6.2.
- Another option would be to bump the version number to MuseScore 5 much sooner, as part of which the development environment is refreshed to Qt 6.2 LTS and support for legacy operating systems is dropped.
Let's have the discussion. At least the community (and those potentially excluded by the decision) will have some insight into the decision.