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, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
