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 >