Releasing Deprecated modules and Tier 4 Definition

[Aleix Pol]

On Sat, Mar 15, 2014 at 4:59 PM, Kevin Ottens <ervin at kde.org> 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.
> 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
>
>
> _______________________________________________
> Kde-frameworks-devel mailing list
> Kde-frameworks-devel at kde.org
> https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
>
>
Hi,
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.

1) Tier Deprecated would probably contain KRunner too, especially if
sprinters ends up joining the frameworks party, which I'm unsure.

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.

Aleix
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20140315/6761fc3a/attachment.html>