Exemptions to try KF "grow" vs. consistent experience (Re: Submitting Grantlee as a KF5 Framework)
Albert Astals Cid
aacid at kde.org
Sat Dec 28 22:49:15 GMT 2019
El divendres, 27 de desembre de 2019, a les 11:03:25 CET, Volker Krause va escriure:
> 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
Can you give an example here of the naming conventions that are being broken?
Is this about the
a) include dirs below subdir KF5/
b) CMake modules with KF5 prefix
c) CMake imported target in KF5 namespace
We can fix that by simply doing it both ways, no? I.e. doing it the "right KF5 way" but still keeping the old way for a while for compat.
More information about the kde-core-devel