[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-community
Subject:    Re: Proposal unify back our release schedules
From:       Volker Krause <vkrause () kde ! org>
Date:       2024-04-21 8:27:09
Message-ID: 20401707.MxBFCYsqjC () vkpc27
[Download RAW message or body]


On Sunday, 21 April 2024 00:37:03 CEST Ben Cooksley wrote:
> On Sun, Apr 21, 2024 at 1:51 AM Kevin Ottens <ervin@kde.org> wrote:
> > Hello,
> > 
> > On Saturday 20 April 2024 15:12:48 CEST Ingo Klöcker wrote:
> > > On Freitag, 19. April 2024 22:40:38 CEST Ben Cooksley wrote:
> > > > On Sat, Apr 20, 2024 at 4:39 AM Kevin Ottens <ervin@kde.org> wrote:
> > > > > The example you give shows Plasma depending on Gear, this shouldn't
> > > > > happen, so
> > > > > I'd argue: let's fix that instead.
> > > 
> > > In my opinion the same goes for Gear depending on Plasma.
> > 
> > Agreed, just didn't want to muddy my message and so focused on only one
> > direction. But it's definitely a topic to explore as well.
> > 
> > One thing I'm unsure for instance is: do we want to make Gear -> Plasma
> > dependencies completely forbidden?
> > 
> > We might consider this going one step too far. I could understand if a
> > Gear
> > app wants to provide "more integration" in a Plasma session. So mandatory
> > Gear
> > -> Plasma dependencies, I agree are to forbid, but optional ones? I'm less
> > certain.
> 
> I've considered whether it was feasible to ban such dependencies in the
> past, however always ended up in the position that it wasn't feasible to do
> so.
> This will require a degree of projects being moved around, code being
> broken out into separate modules, etc. but I think it is solvable given
> enough commitment to do so.
> 
> We probably need a home for "not quite Frameworks but shared libraries none
> the less" to make this achievable.
> 
> The usual tripping points ended up being:
> - Various graphics and multimedia libraries such as libkdcraw, libkexiv2,
> etc
> - Various PIM libraries, often related to Akonadi integration for Workspace

One approach to solve that is/was to actually turn those into frameworks. A 
bunch of PIM libraries were moved over time (KContacts, KCalendarCore, KDAV, 
etc) already. More were lined up, the KF6 transition just put a pause on that, 
but e.g. KMime not too long ago received a bunch of API fixes in preparation 
for this.

However, before continuing down that road I'd like to see a decision on the KF 
release schedule first now. With a much longer release cycle this becomes a lot 
less interesting to do.

Regards,
Volker
["signature.asc" (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]