Naming scheme for Qt5/KF5-based libraries outside of KF5
Boudhayan Gupta
bgupta at kde.org
Sun Sep 27 10:46:20 UTC 2015
On 27 September 2015 at 15:29, Sune Vuorela <nospam at vuorela.dk> wrote:
> On 2015-09-26, Boudhayan Gupta <bgupta at 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
More information about the Kde-frameworks-devel
mailing list