On Mon, Dec 3, 2018 at 10:31 PM René J.V. Bertin <rjvber...@gmail.com> wrote: > > 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.
Not really, because it won't be long before 5.10 is no longer any of the current mainstream distributions. > > 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)! As mentioned in my mail, this applies to everything but Frameworks. It doesn't affect Frameworks - which will continue on Qt 5.9 at this stage. > > 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? For some it's mandatory. > > 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? The CI system has no way of knowing what a project says it requires. It relies on it's own configuration files to dictate what jobs are generated, and those jobs in turn determine what platform they're run on. What i'm referring to here is the manual process of having to go and exclude various projects which do use PIM libraries (the CI system doesn't have a concept of optional, it's either needed or not present at all). The only way to do this will be by hunting through the dependency graph, which is easier said than done (because Application A uses library B which uses library C which in turn uses PIM library D) Individual project failures might not seem too bad, apart from the fact it's me (or one of the handful of people familiar with the CI system configuration) who will have to update the configuration for many projects (which will result in either lots of Sysadmin tickets, or a ton of various people spending time hunting these issues down). Note that in order for the CI system to operate properly the "Dependency Build" jobs need to be able to run successfully (otherwise you'll have missing dependencies when you go to run a build). In most cases it won't be jobs themselves that fail, it'll be the Dependency Build jobs - and because these jobs start from scratch (ECM, then up through Frameworks and so on until every project's dependencies have been built) it's extremely expensive to keep running these jobs as they occupy builders for quite a bit of time. > 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? > We see those on a semi-regular basis - as those who have seen QtTest casting issues will be well aware. > > R. Cheers, Ben