[kde-community] Non Api-stable libraries/frameworks - Re: Applications in KDE Generation 5

[Sebastian Kügler]

On Thursday, January 16, 2014 12:00:36 Kevin Krammer wrote:
> On Thursday, 2014-01-16, 01:33:34, Albert Astals Cid wrote:
> > El Dimecres, 15 de gener de 2014, a les 21:47:17, John Layt va escriure:

> > > * Application domain-specific libraries such as libkipi or libkcddb
> > > may now be better organised under Frameworks rather than their
> > > modules, where they could gain a wider user base and a clearer
> > > maintenance viability.  Can we have a Frameworks category for non-api
> > > stable libraries?
> >
> > I am not sure I would call it "Frameworks", but yes, that makes total
> > sense, for example at the moment our mobipocket library just uses QtCore
> > and QtGui but since it's using all the KDE cmake stuff it's not that easy
> > to re-use "from the outside".
> 
> I also think it is important to not call those "Frameworks", because it 
> dilutes the assumption we want developers to make about Frameworks, e.g. 
> stable, maintained, scheduled releases, etc.

This is a very important point. We've had some discussions during the Plasma 
sprint (which I'm currently attending), and "make it a Framework" was offered 
as a solution to scope some libraries. While I think that should in principle 
be possible, separate libraries do not automatically become frameworks.

The fact that they're split and less interdependent makes it easier to have a 
bigger set of libraries, but it's really important that we only ship libraries 
that satisfy a certain set of qualities, such as API and ABI stability, 
complete documentation, unit-testing, etc. Otherwise, our newly created 
"Frameworks brand" will quickly lose its meaning and value, and worse, devalue 
other, high-quality libraries' reputations. Strong requirements are a good 
thing here.
-- 
sebas

http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9