[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:       Volker Krause <vkrause () kde ! org>
Date:       2019-10-25 6:39:24
Message-ID: 3019290.44csPzL39Z () vkpc19
[Download RAW message or body]


On Thursday, 24 October 2019 21:59:02 CEST David Faure wrote:
> 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.

In case this ends up being activated in production builds, this would however 
require our ABI isn't changing by deactivating deprecated bits. Enum values 
and vtable layouts look particularly in danger for this. I'm not sure this was 
considered by deprecations predating the new possibilities.

Regards,
Volker
["signature.asc" (application/pgp-signature)]

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