[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: QT_DEPRECATED_BEFORE/KF_DISABLE_DEPRECATED_BEFORE_AND_AT=0x060000 considered harmful
From:       David Faure <faure () kde ! org>
Date:       2019-10-24 19:59:02
Message-ID: 5051825.29KlJPOoH8 () asterixp50
[Download RAW message or body]

On jeudi 24 octobre 2019 18:49:02 CEST Volker Krause wrote:
> On Thursday, 24 October 2019 16:41:58 CEST David Faure wrote:
> > On jeudi 24 octobre 2019 16:32:32 CEST Volker Krause wrote:
> > > Maybe we should look at this separately for stable branches and master?
> > 
> > Makes sense for Applications (assuming we lower down from 0x060000 to
> > latest- tested when master itself is branched into a stable branch).
> 
> Exactly.
> 
> > No such separation in KF5 itself though, there the question remains.
> > But we have the task in our KF6 dashboard, so hopefully we won't forget to
> > regularly increase the number and fix compilation. We as in, any KF6
> > volunteer, not necessarily Laurent.
> 
> There's two things to look at for Frameworks I think:
> - Qt: only two more version updates remaining for 5, or at most two per
> year. Doing this as an explicit/script-assisted bump is probably
> acceptable, and to to be sure we don't forget this it could maybe
> automatically be determined as max(explicitly deprecated qt version,
> minimum required qt version).

I like the overall idea. Looking at implementing it though, it doesn't seem 
trivial to do the max() as CMakeLists.txt logic. But it doesn't have to be, 
this is static at any given point in time, so I'll just do that in 
release-tools/increase_qt_version.sh

> - other KF5 dependencies: it might be worth setting this to the current KF5
> version. At least at the point where we are deprecated-clean once, and
> accept a deprecation policy that requires Frameworks to be ported before
> the deprecation is executed. In such a scenario this would never trigger,
> but provide a safe guard we follow our own rules.

Very clever. Yep, this makes a lot of sense. I'll do this too.

-- 
David Faure, faure@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5



[prev in list] [next in list] [prev in thread] [next in thread]