On 27 September 2015 at 15:29, Sune Vuorela <nos...@vuorela.dk> wrote: > On 2015-09-26, Boudhayan Gupta <bgu...@kde.org> wrote: >> We could kill two birds with one stone here, creating a new KDE module >> just for libraries (say, KDE Companion Libraries or something) and put >> everything in the KC5 (or whatever we decide) namespace. > > By doing this, we kind of make it a thing to .. become. I do think that > shared cross-repository libraries that aren't frameworks should be > avoided as much as possible, and for the few ones where it isn't > possible for specific functionality we should still try to limit it.
What exactly is wrong with shared cross-repo libraries? Take libPurpose for example. It's a great little utility that many apps can use, but it's certainly not mature enough to be a framework. I'd want it in a place where many people can use it. > It is libraries that might change abi and api, and that's generally a > mess, especially if the users have different release schedules. And > people will use an available shared library. What's wrong with people using a shared library? That's what they're for. A new component must be aligned with the Applications release-unit, and since Applications are primary (only?) users of the libraries, and API/ABI break shouldn't cause any problems at all, given that apps in the (eg) 15.12 release will only depend on the 15.12 version of the library. Also, why are we assuming API/ABI will be broken? Can't developers be trusted to be strict with their APIs? >> I'm all for just putting everything in KDE Support, using the KS5 >> namespace and removing the tier0 restriction from Support. > > KDE Support is our 'low level' libraries, but many of them has become > frameworks, which I think should also be the road ahead. Again, if it can become a framework, make it a framework. If it can't, put it in Support and release it with Applications. > > /Sune Cheers, Boudhayan _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
