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

List:       kde-devel
Subject:    Re: Proposal unify back our release schedules
From:       "Jakob Petsovits" <jpetso () petsovits ! com>
Date:       2024-04-19 20:51:55
Message-ID: b932fe39-1d30-431e-92f0-ac46be931f3a () app ! fastmail ! com
[Download RAW message or body]

Others have made convincing arguments for not tying the projects together from an \
engineering point of view, which I find easy to agree with. I also like the current \
monthly KF schedule in that it allows me to submit MRs early on in a Plasma \
development cycle and use them in Plasma shortly afterwards. If KF release cycles \
were longer, there would be more of an incentive to just stick everything into a \
common library within Plasma directly, which doesn't benefit as many people.

What could also help with proper isolation of components is a change in build system \
defaults. If I call kdesrc-build today with --include-dependencies for any Plasma or \
Gear app, by default it will build all KF dependencies from source. Now that all the \
megarelease is out, we might want to consider relying on distro packages for KF6 by \
default, in the same way that Qt is not built by default either. This would \
underscore the nature of Plasma and Gear master relying on released KF, and save some \
wasted energy for people who aren't contributing to KF.

But I also wanted to emphasize that we're actually that far off from the marketing \
aim either. Aligned releases are still very doable without forcing everyone into a \
"live at HEAD" model. Neal's suggestion deserves a closer look imho:

On Fri, Apr 19, 2024, at 11:50 AM, Neal Gompa wrote:
> One way I think that would work well would be to realign the schedules
> so that when Plasma shifts to semi-annual releases, Frameworks and
> Gear would be re-aligned so that there *would* be a release that lines
> up with it. That doesn't mean both can't continue to have more
> releases separately, but having a release that lines up for Plasma
> would help things considerably.
> 
> The monthly release of KDE Frameworks has its downsides, and I think
> in one conversation elsewhere, I suggested that KF moves to a
> quarterly release cadence, where two of the releases line up with
> Plasma to become MegaReleases. Gear already releases three times a
> year, and switching to four times might not be so bad.
> 
> But even if KF doesn't change and remains monthly, then it still can work.

This would mean:

KF: every month
Gear: every 3 months
Plasma: every 6 months

With Gear and Plasma aligning for a semi-yearly release. Stand-alone Gear releases \
get their extra announcement when the full Plasma+Gear announcement is far into the \
past and future, with no promo timing conflicts to worry about.

Honestly I don't think that KF even needs to be aligned at all if it sticks to \
monthly: Assuming an expanded QA/beta/bugfix period (at least 4-6 weeks?) that the \
longer 6-month cycle surely deserves, any KF fixes from the beta period will either \
get released before Plasma is even out, or very soon after.

Perhaps an extra patch-level release of KF can be inserted around the time of \
Plasma's .0 if an important fix is needed fast. Switching KF from monthly to \
semi-yearly seems overkill if we just need to get post-release fixes out a little \
sooner.

- Jakob


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