Proposal unify back our release schedules

[Neal Gompa]

On Fri, Apr 19, 2024 at 11:35 AM Volker Krause <vkrause at kde.org> wrote:
>
> On Freitag, 19. April 2024 11:04:33 CEST Carl Schwan wrote:
> > * 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.
>
> The fast feature-releases of KF have major advantages though, comparing to how
> things worked prior to 5. They allow apps to work against released (and thus
> distro-packaged) frameworks while still making it practical to contribute
> needed features to KF directly.
>
> The alternatives are:
> * Depend on KF master (like Plasma does), significantly increasing the
> threshold of entry for new contributors, especially for more self-contained
> apps, where you'd now have to build 70+ repos rather than a few.
> * Depend on the latest release but develop new features locally rather than in
> KF. I'm not sure whether we have meanwhile finally cleaned up all the forked
> kdelibs classes in PIM from the 3 and 4 era due to that.
> * Depend on the latest release and wait for new features to become available
> before making use of them in the app, effectively increasing the delay to reach
> users to twice the release cycle.
>
> Ie. this makes contributing to KF less attractive from an app developer
> perspective.
>
>
> The main issues with out-of-sync KF and Plasma should have been solved with
> some frameworks being moved to Plasma with KF6, if there is more of this
> remaining we should look at the specific cases, for the vast majority of
> frameworks I don't think we have a problem there.
>
> > * Helps with outside usage of our frameworks. These didn't get as much
> > success as we were hoping when splitting. I think having a stable branch
> > for Framework might help but this is only a guess. It would be interesting
> > to know of cases where people considered using some Framework and to know
> > why they decided against or for it and if this proposal would helps or not.
>
> I disagree with the often repeated statement that this wasn't successful. It
> might not happened as widely and visibly as we might want, but KF is most
> certainly used vastly more often than kdelibs ever was. And the release
> schedule isn't the impediment here, it's things like dependencies and the
> build system making it hard to vendor copies.
>
> > In effect this proposal would mean:
> >
> > * We do one major release every 4 months and then minor releases with a
> > frequency based on the Fibonacci numbers as this releases cycle works very
> > well for Plasma. Naming could be either YY.MM or Major.Minor.Path. We could
> > unify that for one or the other one. Or let each component keep their
> > current versioning scheme depending whether we want to merge Plama and Gear
> > as product or keep it separate. I'm a bit undecided about this.
>
> From my app developer perspective that is fine, Fibonacci rather than
> equidistant patch releases look like an improvement to me. However, assuming
> the feature release interval basically remains the same.
>
> AFAIK Plasma is discussing a 6 month interval though, and I do understand
> longer cycles are better for promo, but it means users have to wait longer for
> features. It therefore also matters whether we are tying Plasma's release to
> Gear or Gear's releases to Plasma here.
>
> > * "KDE Framework" will still exists as an entity and its ABI and API
> >   compatibility requirement. Only change is the release frequency and the
> > introduction of a stable branch in sync with the other components.
>
> That part I'm against for the above mentioned reasons, KF's release frequency
> is a major feature of it.
>

As a distribution, I found it tremendously helpful to integrate and
qualify the MegaRelease. That doesn't mean that we need *every*
release of KF and Gear to be MegaReleases.

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.


-- 
真実はいつも一つ！/ Always, there's only one truth!