Exemptions to try KF "grow" vs. consistent experience (Re: Submitting Grantlee as a KF5 Framework)
vkrause at kde.org
Fri Dec 27 10:03:25 GMT 2019
On Thursday, 26 December 2019 19:25:09 CET Albert Astals Cid wrote:
> El dimarts, 24 de desembre de 2019, a les 13:05:23 CET, Friedrich W. H.
Kossebau va escriure:
> > Am Montag, 23. Dezember 2019, 09:57:57 CET schrieb Volker Krause:
> > > On Sunday, 22 December 2019 09:46:02 CET Dominik Haumann wrote:
> > > > Hi all,
> > > >
> > > > in any case, maybe the discussed points should go to the KF6
> > > > workboard?
> > > > https://phabricator.kde.org/project/view/310/
> > > >
> > > > I indeed believe that consistency in the KF5 world is an important
> > > > feature,
> > > > so Friedrich does have a point here. Other framework additions had to
> > > > adapt
> > > > as well (what comes to my mind is renaming of KQuickCharts or
> > > > KCalendarCore).
> > >
> > > There is one important difference between KCalendarCore/KQuickCharts/etc
> > > and Grantlee/QKeychain/etc though. The former had no previous release
> > > promising a public API and therefore only KDE-internal users. The
> > > latter have such releases and guarantees, and a significant
> > > KDE-external user base. That's what makes me consider a transitional
> > > pragmatic exemption from certain conventions, if we assume it would
> > > help to grow our external user base, and thus the pool of potential
> > > contributors.
> > Having to make exemptions shows a principal design flaw though: if the
> > idea is to pull in more libraries into KF, incl. some with previous
> > releases & thus existing userbase hoping on longer-term stable ABI, the
> > same will also happen in the KF6 series. And even for the currently
> > discussed two libs Grantlee & QKeychain it means at least 1 1/2 years &
> > longer (assuming KF 6.0.0 is coming then, and see how long kdelibs4
> > survived) for being just "exemptions". It's rather that the "exemptions"
> > become part of the rules that way.
> Which kind of exceptions are we speaking about?
> ABI stability? or?
The opposite actually :) It's about keeping existing API/ABI of frameworks
with a significant (KDE external) user base when joining KF5, until the next
major release, even if that means making compromises regarding e.g. our naming
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 195 bytes
Desc: This is a digitally signed message part.
More information about the kde-core-devel