Proposal unify back our release schedules

[Kevin Ottens]

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

> > > > * We currently don't have a stable branch for Framework and it takes
> > > > often
> > > > up to one month for fixes to be deployed. The Framework releases is
> > > > also
> > > > not in sync with either Gear nor Plasma while these two modules
> > > > heavily
> > > > make use of Framework and contribute to Framework.
> > 
> > Changing the Frameworks release cadence away from monthly isn't going to
> > get fixes out any faster - as if you are using distribution packages it
> > still has to be packaged.
> > If anything it will make them take longer as the Frameworks release would
> > end up being every couple of months instead of monthly? (you can always
> > build Frameworks locally if you need the fixes now)
> 
> For (non-rolling) distributions that update packages on patch releases but
> not on minor releases it would make a difference if there where patch
> releases of Frameworks. Not all distributions can follow and backport
> important fixes in Frameworks. At worst, users will have to suffer a bug in
> Frameworks until the next LTS release.
> 
> Regards,
> Ingo
-- 
Kevin Ottens, http://ervin.ipsquad.net

enioka Haute Couture - proud supporting member of KDE
https://hc.enioka.com/en
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-community/attachments/20240420/e1233104/attachment.sig>