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
> conventions.
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
**********
stuff?
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.
Cheers,
Albert
>
> Regards,
> Volker
>
More information about the Kde-frameworks-devel
mailing list