On 17/03/14 15:25, Aurélien Gâteau wrote: > 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".
... which I think is where the confusion about tier 4 has come from. This maturity information would be familiar to anyone familiar with the Qt Project's processes, which would be a bonus. Alex _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
