On Fri, Apr 19, 2024 at 11:35 AM Volker Krause <vkra...@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!
