Should BC be applied to new libraries? (was RFC: New Module kdesdklibs?)

[Alexander Neundorf]

On Saturday 25 July 2009, David Jarvie wrote:
> On Saturday 25 July 2009 16:06:48 Andreas Pakulat wrote:
> > Hmm, seems we already have quite a lot modules with inter-dependencies.
> > As I'm also not sure about being able to keep BC for all of KDE4
> > lifetime once we release the new module I'll just put the library into
> > kdesdk for now and let kdevplatform depend on kdesdk. Same for being
> > able to use komparepart.
>
> This isn't the most satisfactory outcome - it would be better if shared
> code could be separated out into library modules. But I understand your
> reasons, which prompts me to wonder again if we have the right BC policy
> for new libraries.

I think the BC policy applies only to libraries from kdelibs. At least AFAIK 
(correct me if I'm wrong) the lib(s) from kdegames don't promise to keep BC.

> For established libraries, there are very good reasons to insist on BC
> being maintained for the life of KDE4. What I would question is whether
> there shouldn't be another category of "new library", which for a limited
> period of time - say 6 or 12 months - would be allowed to break BC.
> Provided the potential for breakage was made as clear as possible to
> developers using the library, I don't see the harm. The wider testing of
> the library which could result from making the library available for
> external use should help to improve the code and API, before it has to be
> set in stone. Without wider testing, it will not always be possible to
> develop the "perfect" API, so does the current policy not actually tend to
> hinder development of new libraries?

Having the libraries in a separate module (kdesdklibs) would also make it 
easier to build the applications using these libs separately, i.e. not as 
part of their complete module, because then e.g. libkdesdklib.so (or what the 
name is) will always be a project-external library and not an in-project 
library if built as part of the complete module, and a project-external 
library when built separately.

So I think having them in a separate module is a good think in this regard.

Alex