Deprecation Defines

[Matthew Dawson]

On July 8, 2014 10:50:18 PM David Faure wrote:
> > I agree.  I figured the first step was to come up with a draft policy and
> > post to the list for comments, and as I said I'm trying to get a new
> > contributer to help (they have lots of experience writing documents, and
> > have a strong technical background).  Time, as always, limited our ability
> > to get it written.
> 
> I think we need to decide before we can write it out :-)
I was going to come with a template basically, with some ideas thrown against 
a wall.  A rough draft.

> > I don't see option 1) being usable without fixing cmake to avoid the
> > redefining warnings (though I imagine that is a small task).  Also, I
> > don't
> > think any general purpose distribution would enable it, as that option
> > would break SC and BC anytime new deprecated features are added.  For
> > single purpose devices, it's not a problem.  But single purpose devices
> > are rapidly shrinking.
> 
> Not necessarily single-purpose, just different BC than desktop linux.
> E.g. Meego could have decided "we ship KF-5.0 without deprecated stuff,
> to make it smaller".
But imagine another virtual function is deprecated in KF-5.1.  Now, if you 
update from KF-5.0 to KF-5.1, anything linked to that library just broke as 
there is a BC change.  Anything on that system needs to recompile.  People 
will not be happy if the device upgrade story includes re-downloading all the 
software.  And if anything is closed source, you can't upgrade until it gets 
fixed.

> 
> > Option 2 definitely has its uses, but as you say deprecation warning
> > should
> > take care of that.  Come to think of it, one problem with option 2 is that
> > developers may enable that in their production build scripts, and thus
> > with
> > a new release of KF5 deprecating new behaviour, will break old
> > applications.
> 
> This is why I rather see *application* developers setting it (only within
> their own app, they typically don't care about others). New KF5 releases
> would then force them to port away from the newly-deprecated stuff.
I was talking about application developers there too.  Again, imagine a 
developer uses function X, and release there code with their build scripts 
always setting the NO_DEPRECATED.  If in KF-5.x+1 deprecates X, suddenly there 
code fails to compile (but it will run fine).  It is like releasing code with 
"-Wall -Werror" turned on all the time.

> 
> But yeah, the Qt solution with version-specific deprecation
> (QT_DEPRECATED_SINCE) is much better, we should adopt something like that.
> This way, you can ensure your code keeps compiling "without the stuff that
> was deprecated in 5.1", without getting a compilation error if someone
> suddenly installs KF 5.2 which deprecated new stuff. This means not using
> the stuff currently in cmake then, but something more evolved based on the
> project's version number...
QT_DEPRECATED_SINCE would erase my complaint, as the new deprecations won't 
disappear on the application.
-- 
Matthew
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3885 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-buildsystem/attachments/20140708/9e2a3610/attachment.p7s>