Actions for 2025-12-01 release

[hjmjohnson]

As PythonQt is updated to provide more consistent support for Qt6, several key discussion points should be considered to optimize development efforts.

I am proposing a draft set of recommendations that SHOULD BE REFINED.

For a 2025-10-15 (arbitrarily chosen) target date:

• Only Python 3.9 and above are supported in the main branch of PythonQt.
• Python 3.13 part of the CI testing infrastructure
• Only Qt 5.15 and above are supported
• Qt 6.10 is part of the CI testing infrastructure
• Qt 6.10 on macOS arm platform is supported
• --some legacy minimum ubuntu platform-- continues to be supported
• --some legacy windows platform-- continues to be supported

For a 2025-11-01 (arbitrarily chosen) target date:

• A CMake build and test infrastructure is implemented (qmake2cmake_all --min-qt-version 6.10 .)

Feel free to add, reject, or modify this proposal.

Guiding Principles:

• wait until about 12-18 months after support is dropped upstream before removing support in PythonQt.

[hjmjohnson]

	•	Qt 5.9 → 5.15 (2017–2020)
	•	CMake support matured: most modules had proper CMake config files, and documentation began encouraging CMake for new projects.
	•	Qt 5.15 (the last Qt 5 release) specifically noted that CMake is the preferred build system going forward, though qmake remained supported.
	•	Qt 6.0 (Dec 2020)
	•	CMake became the official build system.
	•	qmake was deprecated (still shipped for compatibility in Qt 6.0–6.4, but no longer developed).
	•	Qt documentation from 6.0 onward recommends CMake for all new projects.
	•	Qt 6.2 LTS (2021)
	•	First LTS Qt 6 release, fully CMake-based.
	•	By then, using qmake was only advised for maintaining legacy Qt 5 projects.

Additionally, the some of the core tools to facilitate converting from qmake to CMake are being removed from the latest versions of Qt with the understanding that most projects have already converted to cmake. Need to check out legacy Qt codebases to find the conversion tools.

[mrbean-bremen]

I fully agree with using cmake, though I wouldn't remove the qmake support for the time being, as it is working and obviously used by several people, so that would be "qmake continues to be supported for some time".

As for Python: I usually wait for half a year so after a Python version is out of support before dropping it (at least in my Python projects), with some beforehand warning. As Python 3.9 will be out of support only now (basically with the release of 3.14), I would still include it.

Qt: I wrote elsewhere that I'm in favor to support 5.15+, so this is fine with me.

Qt 6.10 on macOS arm shall certainly be supported, and we may also think about supporting Windows and Linux arm builds (though probably not before somebody actually needs them).

[he-hesce]

Hello, the Grinch here.

Do note as PythonQt is used in industrial and scientific applications, there's still a use of platforms such as RHEL 8 and RHEL 9 (including CentOS 8 and Rocky Linux 9). [And also RHEL 7.] Thus I would as always advise you to be careful of Python versions being (officially) out of support given they continue to be supported by Red Hat for quite some time, even decades. In industrial and production environments, the only Python allowed to run is the one provided by the OS vendor so any suggestion to just install the latest Python in a virtual environment is void. This then also includes what Qt version shipped by OS vendor, what bash version shipped by OS vendor, what compiler shipped by OS vendor, et cetera.

We are still using 5.15 and probably will for the next decade as it works and thus it is no reason to use Qt 6. We are also using qmake and there are zero interest and resources in changing the build system to cmake when it is not only not broken but also working perfectly. Particularly when those resources are better spent on critical customer issues. It is practically impossible to convince a customer to pay for changes and potentially for years of instability and issues by changing things which do not need to be changed. "If It Ain't Broke, Don't Fix It."

Generally in industrial/production use, when a solution is adapted, it will need to be supported for 30-40 years. This makes it a challenge to support newer platforms while maintaining support for older but still in support platforms while not also having to keep a specific version of for example PythonQt for each platform. Thus it has in the past been appreciated when PythonQt maintained "legacy" support as the latest version would still work on RHEL 7 while also working on RHEL 9. Of course, I understand this burden is on the user and not the open-source maintainers. I just making my regular Grinch comment that one should avoid being like projects like ObsPy where we are forced to use a different version on each platform (vendor OS) as they drop support for Python versions as soon as there is a new one out.

[mrbean-bremen]

@the_grinch - a couple of things:
As already discussed, we should make some cuts at some point where we stop supporting old versions, simply to keep the project maintainable. Older stable releases can always be used, and if really needed, patch releases for older versions (e.g. 3.4.3) with back-ported fixes are also possible.

Re Python version: I agree that it makes sense to support Python versions longer than the official release. How long, depends on the actual use cases. As mentioned, my own rule of thumb is to support each version about half a year after the official support ends, longer on demand (which has been infamously the case for Python 2.7, and currently I still support 3.7 in one project, though I'm about to cut this).

[hjmjohnson]

Older stable releases can always be used, and if really needed, patch releases for older versions (e.g. 3.4.3) with back-ported fixes are also possible.

In my personal experience:
The effort required to backport fixes to previous stable releases is far less than the effort than the effort needed to simultaneously support an ever-expanding set of computational environments in new releases.

[usiems]

About support of older version: I think it mainly comes down to if we can still test the versions in the CI here on github. Everything else would be too much effort.

I personally don't feel the urge to - just for the sake of it - clean up any old code that still works, but things may still break inadvertently when doing stuff for new versions, so we can only claim (with moderate confidence) that PythonQt still works for those Qt and Python versions that are executed in the CI.

And there are still the older versions of PythonQt. If somebody needs to work with "legacy" systems, they surely can live with an older version of PythonQt, too. But let us still try to make as many users happy as possible with reasonable effort. (Of course the definition of "reasonable" is totally up to debate here. ;)

[he-hesce]

@usiems: sounds good. I am mainly allergic to the ObsPy way of support where the standard answer from developers if you are using anything other than bleeding edge Python that "you should be using Anaconda anyway" and "stop bothering us".

I have been seeing a lot of nice bug fixes lately which I know won't be able to use until we drop CentOS 7 support as I will be stuck on 3.6.1. From my point of view as a user of PythonQt, having a single PythonQt version on all our supported platforms makes things much easier from a testing, certification, and integration point of view. We will remain on 3.6.1 until we can drop CentOS 7 support. Luckily 3.6.1 supports the Python at Qt versions shipping with CentOS 7, RHEL/Rocky 8, RHEL/Rocky 9, and RHEL/Rocky 10.