Hi,
Can't you just configure the CI to use Qt 5.10? I think it's not good to
hardcode an "overzealous" (for lack of a better word) Qt version in projects
that don't require them AND I think that one should support the current LTS
release in as many projects as possible as a general rule of principle.
There's a reason why those LTS releases exist and that should probably be taken
into consideration ESPECIALLY for the KF5 Frameworks (remember why kdelibs4 was
split up)!
People working only on Linux may not realise it but even Qt 5.9 already dropped
support for Mac OS versions that are still widely used.
IMHO, projects that use PIM libraries can decide for themselves how they want
to deal with a Qt minimum version bump in those dependencies, while
distribution maintainers *could* decide to keep those (and only those)
dependencies on an earlier version in order to keep supporting whatever oldest
Qt requirement they have (5.9 for my MacPorts packaging). Also, don't of those
projects have only optional dependencies on PIM libraries?
I tend to see a CI as something that tests software on one or a handful of the
most common configurations. Anyone not using such a configuration is either on
their own or acting as a kind of additional CI.
Bumping the minimum Qt version across the line would decrease the burden on the
CI, but probably increase the burden on distributions, or force them to stop
following upgrades earlier than justified.
Also:
> (otherwise we'll end up chasing down build failures for a long time)
How so? If you want to install project B that requires Qt 5.9+ but also uses
PIM library A which requires Qt 5.1x you're going to need to install something
newer than Qt 5.9 . What kind of build failures we cannot already get ("B
requires PIM library A which is not installed") are you expecting?
There could be errors from *other* projects not depending on PIM libraries, but
if they intend to support an "older" Qt version that implies rather explicitly
that they also intend to address build failures, no?
R.
