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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
