[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:       laurent Montel <montel () kde ! org>
Date:       2019-10-24 15:40:51
Message-ID: 3633590.PcRa3gAmmv () linux-zym0
[Download RAW message or body]

Le jeudi 24 octobre 2019, 16:53:04 CEST Friedrich W. H. Kossebau a écrit :
> Am Donnerstag, 24. Oktober 2019, 16:32:32 CEST schrieb Volker Krause:
> > On Thursday, 24 October 2019 10:50:07 CEST laurent Montel wrote:
> > > Hi,
> > > As discussed with David previously for QT_DEPRECATED, I am against it,
> > > because if we fix a QT/KF_DEPRECATED version we can be sure that nobody
> > > will work for fixing deprecated method until kf6.
> > > If we can"t see that it breaks, everybody will wait for sure (otherwise
> > > it
> > > was already fixed).
> > > When a compilation is broken by a new deprecated method we will fix it.
> > > Nobody fixes a warning by default.
> > > 
> > > I prefere to fix 1-2 deprecated methods between each new kf5 release as
> > > fixed all deprecated method when we will port to kf6.
> > > 
> > > And last argument it's that only me which will port deprecated method.
> > > Because if we need to increase version in CmakeLists.txt you can be sure
> > > that nobody will do it and if I don't do increase it nobody will do.
> > > 
> > > So by default only me will port all deprecated method... And I don't
> > > want
> > > it.
> > 
> > There are valid arguments for both approaches. Maybe we should look at
> > this
> > separately for stable branches and master?
> > 
> > We don't port stable branches away from newly deprecated methods usually,
> > but they might still be built against newer releases of their dependencies
> > (think 19.08.1 against KF 5.64). So for stable branches I think it
> > definitely makes sense to set the disable deprecated versions to whatever
> > was tested at the time of branching, so they remain working going forward.
> 
> This would need some way to note that very version, so it is set
> automatically (no-one wants to do this manually) at branching time.
> Because different software has seen different working efforts, and sometimes
> it is hard to get rid of some deprecated API, so the trigger-version needs
> to be different across repos, even inside.

At the moment all apps compile with 
KF_DISABLE_DEPRECATED_BEFORE_AND_AT=0x060000 (when I added it).
So we can create a script which will raise during branching to kf5.64 for 
19.12.0 for example, and if we have a moment where an apps doesn't build 
against new kf5 in master we decrease it, and for next main release we will 
not change this version.

So an apps build against 0x060000 for 19.12 (against 5.64) we will branch => 
we have a script which change it to 0x05... (I don't know the hexa version).
In 20.04 this apps doesn't build against 0x060000 as we build against 5.70 we 
decrease KF_DISABLE_DEPRECATED_BEFORE_AND_AT at the correct version for 
example 5.68, and the script which will use for branching will not change to 
5.70 for this apps.
I think it's not harder to create a script as it (perl -pi -e 's....')


> > For master however this is less of an issue, as you say we actively port
> > that away from deprecated methods (and at least regarding KF5, we ideally
> > do that even before deprecating a method).
> 
> I see it still as an issue for new-comers but also oldies who want to fix a
> bug in some application, for that checkout the master branch and first will
> have to fight a broken build, due to newer deprecated API.

As volker wrote we will fix code before to deprecate an api (or decrease 
KF_DISABLE_DEPRECATED_BEFORE_AND_AT on specific apps which can't build easily 
without deprecated methods).

> 
> IMHO also git master should always be buildable, and not have planned
> breakage-due-to-new-deprecated-API.

The problem is if we must wait that people fix deprecated method without 
forcing a little, for sure nobody will work on it.

I can see a lot of kde apps which is not maintains (see kdegames for example). 
So nobody will change KF_DISABLE_DEPRECATED_BEFORE_AND_AT

It's too bad as it's the first time that we have a method for removing 
deprecated methods before next big version... I remember when we switched 
between kde2/kde3/kde4/kde5 we made porting when we decided to switch to new 
version, so we didn"t test porting on current branch as we can do now.

Today we can remove deprecated method during ~ 1.5 years. But if we wait that 
each dev decided to increase KF_DISABLE_DEPRECATED_BEFORE_AND_AT we will 
arrive at the same situation as kde5 switching. 



 
> Cheers
> Friedrich


-- 
Laurent Montel | laurent.montel@kdab.com | KDE/Qt Senior Software Engineer 
KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, 
 www.kdab.fr KDAB - The Qt, C++ and OpenGL Experts - Platform-independent 
software solutions 


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