<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sat, Mar 15, 2014 at 4:59 PM, Kevin Ottens <span dir="ltr"><<a href="mailto:ervin@kde.org" target="_blank">ervin@kde.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hello all,<br>
<br>
This week, Aaron brought to my attention (thx!) that we would be releasing 5.0<br>
with modules which would be immediately deprecated. Indeed that's a potential<br>
maintenance and messaging problem.<br>
Also, to make things worse, it looks like it makes the definition of Tier 4<br>
harder. I know David and I often end up arguing about it. As a way out I'm<br>
putting on the table several options in order to gather feedback about them<br>
and see which cocktail we'll apply going forward. Note that we probably want<br>
to figure that out soon in order to not make the release of beta 1 more<br>
difficult than necessary.<br>
<br>
Here are the different options, they're clearly not mutually exclusive.<br>
<br>
1) Split Tier 4 in a Tier 4 and a Tier Deprecated :)<br>
Currently we can consider Tier 4 as badly defined. It contains both parts with<br>
no API (apidox, frameworkintegration, kfileaudiopreview) mainly for<br>
integration between frameworks and parts with deprecated APIs (kde4support and<br>
khtml ATM). It is maybe a good reason to split that in two parts:<br>
* Tier 4 containing no API, meant for runtime integration between the other<br>
frameworks and tooling (it would contain apidox, frameworkintegration and<br>
kfileaudiopreview);<br>
* Tier Deprecated containing deprecated APIs meant as a temporary porting aid<br>
from kdelibs times (it would contain kde4support and khtml).<br>
<br>
2) Release the deprecated content as a separate product<br>
This one kind of depend on (1). If we redefine Tier 4 and have a separate<br>
group of deprecated APIs, maybe we shouldn't make the deprecated content<br>
official part of KDE Frameworks. In which case we'd release two products: KDE<br>
Frameworks for everyone and KDE Porting Aids (in lack of a better name)<br>
containing the deprecated APIs. Clearly they are not of interest to the same<br>
audience and that could warrant having two products.<br>
<br>
3) Roll all the deprecated modules into KDE4Support<br>
Instead of having several modules containing deprecated APIs as porting aids,<br>
and since we have already a module labelled as a porting aid, why not merge<br>
everything into a single module? That module obviously would be kde4support.<br>
I admit I'm not sure how practical it would be to merge such a large beast<br>
like khtml in there, it seems doable though.<br>
<br>
4) Announce the deprecated modules will only be released three times<br>
Probably easier if we also apply it with (2). But since they are a porting<br>
aid, it might not make sense to keep the release burden throughout the whole<br>
KDE Frameworks 5 lifetime, to finally stop releasing them in the distant<br>
future of KDE Frameworks 6. That's especially true because of the limited<br>
manpower, and it's not exactly easy on the morale to actively maintain and<br>
release something that everyone is running from. So, what about being honest<br>
with ourselves and limit the number of releases the deprecated modules would<br>
have? If we go that route, I propose only three releases (5.0, 5.1 and 5.2)<br>
and then we stop, that should give plenty of time for people to port away,<br>
especially since it would probably keep working longer (KDE Porting Aids 5.2<br>
would likely work on top of KDE Frameworks 5.4 for instance), it's just that<br>
we won't make any special effort anymore to keep it working.<br>
<br>
That's it for the four ideas to deal with the deprecated modules, now let's<br>
find a working cocktail.<br>
<br>
Feedback and opinions are of course welcome.<br>
<br>
Regards.<br>
<span class="HOEnZb"><font color="#888888">--<br>
Kévin Ottens, <a href="http://ervin.ipsquad.net" target="_blank">http://ervin.ipsquad.net</a><br>
<br>
KDAB - proud supporter of KDE, <a href="http://www.kdab.com" target="_blank">http://www.kdab.com</a><br>
<br>
</font></span><br>_______________________________________________<br>
Kde-frameworks-devel mailing list<br>
<a href="mailto:Kde-frameworks-devel@kde.org">Kde-frameworks-devel@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/kde-frameworks-devel" target="_blank">https://mail.kde.org/mailman/listinfo/kde-frameworks-devel</a><br>
<br></blockquote></div><br></div><div class="gmail_extra">Hi,</div><div class="gmail_extra">First of all, I agree that the definition of Tier 4 is gray at the moment, escentially it's mostly things we don't want people to depend on.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">1) Tier Deprecated would probably contain KRunner too, especially if sprinters ends up joining the frameworks party, which I'm unsure.</div><div class="gmail_extra">
<br></div><div class="gmail_extra">Personally I think 1 and 2 would work just fine. It's mostly making sure that people doing the promotion will promote what we actually want people to rely on. Option 4 would work too, but we probably want to decide that once we have more applications ported and see what's the status.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">Aleix</div></div>