Update Qt version for Mac Legacy build

[softins]

What is the current behaviour and why should it be changed?

Currently, the Mac Legacy build uses Qt 5.9.9. It is then able to run on MacOS 10.10 (Yosemite) or later. There are some issues with this:

• The automated build in the CI shows a lot of warnings with this version of Qt, although the build does succeed.
• We want to remove the .qm translations files from the repo and have them only built by the Makefile, using the lrelease config entry in qmake. See Build: Generate qm files and embedded resource during build #2393.
• The lrelease functionality in qmake is only available in Qt 5.12 or later.

Describe possible approaches

The compatibility matrix of Qt versions and minimum MacOS version is as follows:

Qt version	Minimum MacOS
5.9	10.10 (Yosemite)
5.10	10.11 (El Capitan)
5.11	10.11
5.12	10.12 (Sierra)
5.13	10.12
5.14	10.13 (High Sierra)
5.15	10.13
6.0	10.14 (Mojave)
6.1	10.14
6.2	10.14
6.3	10.14
6.4	10.14
6.5	11 (Big Sur)
6.6	11

So if we updated the Mac Legacy build to Qt 5.12, we would support 10.12 Sierra onwards. If instead we updated to Qt 5.15, we would support 10.13 (High Sierra) onwards.

The main (non-legacy) MacOS build uses Qt 6.6.1 and therefore only supports MacOS 11 Big Sur or newer. I would expect there still to be demand for supporting at least 10.14 Mojave and 10.15 Catalina for a while yet, and so the Legacy release build is still worthwhile. My own Mac is running Catalina and currently fails to upgrade to Big Sur.

I would favour using Qt 5.15 and therefore dropping support for 10.12 Sierra and older.

Has this feature been discussed and generally agreed?

Not yet.

[ann0see]

I'd like to do an incremental change and use the oldest possible Qt version.
We already had posts about old windows versions. -> Use 5.12

[ann0see]

Hmm. Ok. Wikipedia says that all devices can update from Sierra to high sierra. So maybe we can indeed move up.

[ann0see]

Maybe it makes sense to delay this after the TCP support for more compatibility

[softins]

Maybe it makes sense to delay this after the TCP support for more compatibility

The TCP support is quite an involved project, and there are simpler things I want to do in parallel with it. This being one of them, also the Ubuntu CI one, so that all our CI builds are using at least Qt 5.12 and preferably 5.15 or later. The reason for that is so that we can remove the .qm files from the repo and have lrelease build them from the Makefile generated by qmake.

[ann0see]

I understand, however I'd prefer to have older versions having the latest "under the hood improvements" if that's the way to move forward before we drop support. This helps longer them to have longer support. We can drop the whole translation feature for it if needed before updating.

[softins]

Hmm, that's frustrating. I think dropping translations would be a poorer choice than dropping support for archaic versions of macOS. How about if we went to Qt 5.12 first then, instead of 5.15 for Mac Legacy? That would just drop Yosemite and El Capitan, but retain Sierra.

Regarding "under the hood improvements", I believe TCP support and IPv6 directories should be released together and are significant enough to be called Jamulus 4.0.0. That would then be a point at which we could also drop support for Sierra. But I don't want other worthwhile improvements to be stalled waiting for that to happen.

[ann0see]

I mean the thing is that then people on those versions would be stuck.
If we don't think that's a value ok. Unfortunately it seems as if people still asked on the forums for legacy OS - especially on windows.

[softins]

I mean the thing is that then people on those versions would be stuck. If we don't think that's a value ok.

Not completely. They can still use 3.10.0 which will be forward- and backward-compatible with newer versions. The number of people stuck on the very oldest OS versions will be reducing all the time.

Unfortunately it seems as if people still asked on the forums for legacy OS - especially on windows.

Do you mean in Github discussions, or somewhere else? I've just checked the SF forums, but they only go up to 2021.

Anyway, I've just updated the associated PR to use Qt 5.12.12 instead of Qt 5.15.2 for Mac Legacy. Once it's built, I'll try the Mac Legacy version on my Mac and if it's ok, I'll change the PR from draft to ready.

[ann0see]

#2955 (comment)

But also https://github.com/orgs/jamulussoftware/discussions/3222 - I think you personally also run Catalina?

Old Macs may still run well.
We can probably not make everyone happy. There is a possibility to update ancient Macs to Sonoma via OpenCore legacy patcher. So in theory you can also go the unsupported route.

[softins]

But also https://github.com/orgs/jamulussoftware/discussions/3222 - I think you personally also run Catalina?

Yes I do. I tried updating to Big Sur, but ran into a problem and the upgrade refused to complete after failing to verify something. Thankfully without destroying the existing installation of Catalina.

That's why I am particularly interested in Mac Legacy.

Old Macs may still run well. We can probably not make everyone happy. There is a possibility to update ancient Macs to Sonoma via OpenCore legacy patcher. So in theory you can also go the unsupported route.

OK. The app store suggests that my particular Mac ought to be able to run Monterey, but I don't want to try in one big step.

[softins]

Anyway, I've just updated the associated PR to use Qt 5.12.12 instead of Qt 5.15.2 for Mac Legacy. Once it's built, I'll try the Mac Legacy version on my Mac and if it's ok, I'll change the PR from draft to ready.

Well the CI build for Qt 5.12.12 does seem to install and run ok.

But I've had a look at the build logs. The build for Qt 5.12.12 shows a lot of deprecation warnings about implicit copy constructors. The build for Qt 5.15.2 doesn't show those warnings, suggesting that 5.15.2 has been improved in some way to avoid this.

For that reason, I would prefer to go back to using 5.15.2 in my PR, and specifying that we support High Sierra onwards.