Bump min dep versions of Qt & KF to 5.9 & 5.44
AbandonedPublic

Authored by kossebau on Jul 19 2019, 12:44 PM.

Details

Reviewers
kfunk
flherne
Group Reviewers
KDevelop

Diff Detail

Repository
R32 KDevelop
Branch
bumpqtkfmin
Lint
No Linters Available
Unit
No Unit Test Coverage
Build Status
Buildable 14130
Build 14148: arc lint + arc unit
kossebau created this revision.Jul 19 2019, 12:44 PM
Restricted Application added a project: KDevelop. · View Herald TranscriptJul 19 2019, 12:44 PM
Restricted Application added a subscriber: kdevelop-devel. · View Herald Transcript
kossebau requested review of this revision.Jul 19 2019, 12:44 PM

(Using phabricator to make sure people are triggered for this central change)

Given we lost Kevin's CI, and have no other feedback currently about whether kdevelop code actually builds and works for the current min versions, I propose to bump the Qt & KF versions a bit to limit the scope of their versions we officially claim to support with upcoming 5.4

Looking at interesting non-rolling-release systems where Qt & KF are part of the system there are at least:

  • Ubuntu LTS 18.04: Qt 5.9, KF 5.44
  • openSUSE Leap 15.0: Qt 5.9, KF 5.45
  • Debian Buster: Qt 5.11, KF 5.54

Any other platforms where Qt & KF are part of the system and which we want to support for building KDevelop from source with what is in-the-box?

kfunk accepted this revision.Jul 19 2019, 3:12 PM
kfunk added a subscriber: kfunk.

Sorry for my conservative thinking again: Debian Buster (10) is still /very/ fresh; it was just released a couple days ago. The former "oldest" supported distro was Debian Stretch (9) with Qt 5.7 and KF 5.28. That'll stick around for some time.

Also see discussions from the former version bump: https://phabricator.kde.org/D16495#359725

Repeating myself, but: I do not think bumping versions "just because " has any value. But you got a point there: We currently do not or cannot test whether KDevelop builds under this configuration at all. Although we do not test whether it builds under the new minimum supported configuration either.

Anyhow, so be it :)

+1

This revision is now accepted and ready to land.Jul 19 2019, 3:12 PM
flherne accepted this revision.Jul 19 2019, 4:52 PM
flherne added a subscriber: flherne.

As the person who raised the Debian Stretch issue last time, I don't think it's worth caring about now that Buster is released.

By the time 5.4.0 comes out, Buster will have been out for a few weeks, more if there's a beta/RC cycle.

Keeping support for Stretch helps the vast group of users who:

  • Use, for their desktop, a distro notorious for its old software and slow release cadence.
  • Haven't upgraded to even the latest version of that.
  • ...but nevertheless want the absolute-latest version of KDevelop.

No-one would use Debian unless they strongly cared about stability and lack of unexpected changes. KDevelop's x.x.0 releases, let's face it, would never appeal to that demographic. By the time 5.4.1 happens, Stretch will be even staler.

I do not think bumping versions "just because " has any value.

I kind of agree here. Unless we have features that we know are only available with a certain version, we might needlessly restrict how people can build this. They might assume we have a good reason for choosing that specific version and that older versions can't possibly work. When I package stuff for openSUSE, I would never try decreasing minimum versions of dependencies, because I assume that these are actually the minimum. On the other hand, I regularly stumble across software that doesn't specify minimum versions for dependencies, but assumes it's "reasonably recent".

It makes sense to test with some version of Qt & KF so that we can guarantee it works there, but that doesn't mean we have to bump the minimum versions in the CMake config. Perhaps a warning might make sense that this isn't tested, but I wouldn't want to error out.

kossebau abandoned this revision.Jul 21 2019, 12:13 PM

I do not think bumping versions "just because " has any value.

I kind of agree here. Unless we have features that we know are only available with a certain version, we might needlessly restrict how people can build this. They might assume we have a good reason for choosing that specific version and that older versions can't possibly work. When I package stuff for openSUSE, I would never try decreasing minimum versions of dependencies, because I assume that these are actually the minimum. On the other hand, I regularly stumble across software that doesn't specify minimum versions for dependencies, but assumes it's "reasonably recent".

I see. As developer, by all the years, I learned that it restricts my thinking about solutions if considering all the potential places where we one would like to see the software being used, but where it is not currently. Sticking to reality and just discarding those dreams felt like freeing development power usually :)

It makes sense to test with some version of Qt & KF so that we can guarantee it works there, but that doesn't mean we have to bump the minimum versions in the CMake config. Perhaps a warning might make sense that this isn't tested, but I wouldn't want to error out.

That is an interesting idea, possibly we could do that instead, I like it. Would draft something along this instead in the next weeks, but happy to be beaten by someone doing this earlier.

Given there is no strict need to bump, and given your reponses (thanks for doing) were not all completly pro this, discarding now.