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 <er...@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
signature.asc
Description: This is a digitally signed message part.
