Releasing Deprecated modules and Tier 4 Definition

[David Faure]

On Saturday 15 March 2014 16:59:54 Kevin Ottens wrote:
> Hello all,
> 
> This week, Aaron brought to my attention (thx!) that we would be releasing
> 5.0 with modules which would be immediately deprecated. Indeed that's a
> potential maintenance and messaging problem.

Do you have a list of such modules? From Aleix's reply I kind of guess that 
krunner is one of them? I didn't know it was deprecated.

> Also, to make things worse, it looks like it makes the definition of Tier 4
> harder. I know David and I often end up arguing about it. As a way out I'm
> putting on the table several options in order to gather feedback about them
> and see which cocktail we'll apply going forward. Note that we probably want
> to figure that out soon in order to not make the release of beta 1 more
> difficult than necessary.
> 
> Here are the different options, they're clearly not mutually exclusive.
> 
> 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).

Yes.

> 2) Release the deprecated content as a separate product
> This one kind of depend on (1). If we redefine Tier 4 and have a separate
> group of deprecated APIs, maybe we shouldn't make the deprecated content
> official part of KDE Frameworks. In which case we'd release two products:
> KDE Frameworks for everyone and KDE Porting Aids (in lack of a better name)
> containing the deprecated APIs. Clearly they are not of interest to the
> same audience and that could warrant having two products.

Yes.

> 3) Roll all the deprecated modules into KDE4Support
> Instead of having several modules containing deprecated APIs as porting
> aids, and since we have already a module labelled as a porting aid, why not
> merge everything into a single module? That module obviously would be
> kde4support. I admit I'm not sure how practical it would be to merge such a
> large beast like khtml in there, it seems doable though.

No.

A tier can contain multiple frameworks, that's the difference between a tier 
and a framework :-)
It especially means the tier of a framework can change if necessary, while 
this is much harder when everything is bundled together. I want to leave the 
khtml option open (it still has contributors, and could be considered useful 
in some use cases).

> 4) Announce the deprecated modules will only be released three times
> Probably easier if we also apply it with (2). But since they are a porting
> aid, it might not make sense to keep the release burden throughout the whole
> KDE Frameworks 5 lifetime, to finally stop releasing them in the distant
> future of KDE Frameworks 6. That's especially true because of the limited
> manpower, and it's not exactly easy on the morale to actively maintain and
> release something that everyone is running from. So, what about being
> honest with ourselves and limit the number of releases the deprecated
> modules would have? If we go that route, I propose only three releases
> (5.0, 5.1 and 5.2) and then we stop, that should give plenty of time for
> people to port away, especially since it would probably keep working longer
> (KDE Porting Aids 5.2 would likely work on top of KDE Frameworks 5.4 for
> instance), it's just that we won't make any special effort anymore to keep
> it working.

I would say.... we'll see.
As it is written above, all it means is that we're closing the door to fixing 
bugs after 5.2. I don't see any benefit in that, only downsides.
The "effort" in releasing one more module amongst 57+ is negligible.
There's a middle ground between "actively maintain" and "we made it completely 
impossible to even fix one bug".
 ... or to follow a change in ECM, or whatever.

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE, in particular KDE Frameworks 5