autobuild Qt version compatibility issues

[pgScorpio]

referring to https://github.com/pgScorpio/jamulus/actions/runs/2072352613

In the fore mentioned autobuild all Linux builds and the macOS legacy build fail on the same error which has to do with spin_box.setStepType which appears to be introduced in Qt 5.12. so apparently autobuild uses older versions of Qt for Linux and macOS legacy. (The Jack on Windows build failed too, but that's another problem which has to do with the changed Jamulus,pro file)

All versions build ok for me locally using Qt versions:

• Windows: 5.15.2
• Linux: 5.12.8
• macOS: 5.12.12

But unfortunately it's not clear from the autobuild log which Qt version is used in autobuild.

Could we make clear in the autobuild logs which version of Qt is used ?

And should we adjust the minimum required Qt version? or should we document which new Qt functionality NOT to use ? (Though accidentally using them in Qt Designer is very easy. That's what happened here...)

[hoffie]

Could we make clear in the autobuild logs which version of Qt is used ?

The information would still be hidden in the logs, wouldn't it?

For Linux, we don't select a specific Qt version. Instead, we use what Ubuntu 18.04 ships.
For the other platforms, we use aqt to install a specific version.

The information can already be derived from the autobuild logic. Sadly, it's a bit hidden and the place differs depending on where the decision has to be made, but it's possible to dig it up:

jamulus/.github/workflows/autobuild.yml

Line 129 in a9deb22

base_command: QT_VERSION=5.15.2 SIGN_IF_POSSIBLE=1 ./.github/autobuild/mac.sh

I'm not sure how useful knowing the autobuild Qt version would be.
What's more relevant IMO is the minimum supported Qt version, which is documented here:
https://github.com/jamulussoftware/jamulus/blob/master/CONTRIBUTING.md#supported-platforms

As long as we support the Mac legacy build, we cannot up that requirement.

[pgScorpio]

but it's possible to dig it up

But the one you show here (v5.15.2) is definitely not the one used for Linux and Legacy macOS.... (Since those checks failed they must have been done with a version below v5.12)

which is documented here:

Indeed it states "Check to see if any newly introduced Qt calls are available in the minimum supported Qt version, which is currently 5.9"

But this doesn't only apply to new "calls", but anything introduced since version 5.9,... even added property values...
And where can I see what is new since Qt 5.9 ? I had to google the specific failing function call to find out that it was introduced in version 5.12.

A mistake is easily made when changing/adding gui widgets on a newer Qt version, since at that moment you don't even know which function calls or property values are changed when (accidentally) changing a value.
(Yes accidentally is what happened to me. I copied another control, but I must have accidentally changed that specific property while scrolling through the property list. looking for the min, max and current value.)

So I guess it would be wiser to advise to stick with Qt version 5.9 for development ?
And It would surely be wise to do all checks with v5.9 than, to assure compatibility.

[hoffie]

But the one you show here (v5.15.2) is definitely not the one used for Linux and Legacy macOS.... (Since those checks failed they must have been done with a version below v5.12)

Right -- click the link, it's the section for the main macOS build. :)

But this doesn't only apply to new "calls", but anything introduced since version 5.9,... even added property values...

Yep, that sentence might benefit from clarification.
(cc @ann0see)

So I guess it would be wiser to advise to stick with Qt version 5.9 for development ?

That would be a solution for sure. I don't think it needs documentation as it's more a matter of taste. You get quicker feedback when directly using the older version, but you will get feedback in the end (Autobuild) anyway. I've done little UI work, but most code-related work was easy to verify based on the Qt docs.

And It would surely be wise to do all checks with v5.9 than, to assure compatibility.

The checks act both as a compile check and as the actual build. We do not want most of the platforms to use such an outdated Qt version, yet there are editions (macOS Legacy) which require it.

The fact that macOS Legacy uses 5.9 provides a verification that no breakage is introduced. It's right that this does not provide verification that no breakage is introduced in non-mac platform-specific code though.

[ann0see]

Yep, that sentence might benefit from clarification.

@pgScorpio or @hoffie: Could you please add a suggestion to my PR #2561

[ghost]

Jamulus builds with Qt 5.6.1 on IA32 CentOS 6.
Thus you could specify Qt 5.6.1