Releasing Deprecated modules and Tier 4 Definition

[Kevin Ottens]

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.
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).

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.

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.

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.

That's it for the four ideas to deal with the deprecated modules, now let's 
find a working cocktail.

Feedback and opinions are of course welcome.

Regards.
-- 
Kévin Ottens, http://ervin.ipsquad.net

KDAB - proud supporter of KDE, http://www.kdab.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20140315/c2321564/attachment.sig>