Hello, Wished to react to a point in there. :-)
On Friday 19 April 2024 17:33:02 CEST Volker Krause 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. Users waiting longer for features is not necessarily a bad thing though. One of the potential advantages is extra QA time, I assume people are happy to wait if there are less rough edges. Now if we assume the longer cycle don't lead to more QA, this becomes a balancing act... the burden on the users to discover and assimilate new features is real. So it's a bit of a trade-off between dropping a larger set of features on them increasing the chance of such features not being noticed, or pushing less features towards the user at higher frequency which is potentially higher cognitive load (they more likely to notice them all and be in a constant "learning new stuff" and "adapting to change" loop). > > * "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. -- 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.
