On Sat, Mar 15, 2014, at 8:59, Kevin Ottens wrote: > 1) Split Tier 4 in a Tier 4 and a Tier Deprecated :) > Currently we can consider Tier 4 as badly defined. It contains both parts > with > no API (apidox, frameworkintegration, kfileaudiopreview) mainly for > integration between frameworks and parts with deprecated APIs > (kde4support and > khtml ATM). It is maybe a good reason to split that in two parts: > * Tier 4 containing no API, meant for runtime integration between the > other > frameworks and tooling (it would contain apidox, frameworkintegration and > kfileaudiopreview); > * Tier Deprecated containing deprecated APIs meant as a temporary > porting aid > from kdelibs times (it would contain kde4support and khtml).
What worries me with this approach is it feels like comparing apples and oranges here. To me a framework "tier" is about its dependencies, not about its maturity. I would suggest to instead introduce an orthogonal information: maturity, which could have the value: "new", "stable", "deprecated". Aurélien _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
