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