Releasing Deprecated modules and Tier 4 Definition

[Alex Merry]

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