Releasing Deprecated modules and Tier 4 Definition

Aurélien Gâteau agateau at kde.org
Mon Mar 17 15:25:00 UTC 2014


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


More information about the Kde-frameworks-devel mailing list