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

[Andreas Pakulat]

On 25.07.09 16:33:10, 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.

It actually will be in a library still, but not a separate module. I'm
not sure of the benefit of that anymore as the only reason I wanted to
do it was because I was under the impression that one module must not
depend on another. Packagers already split our modules into separate
parts and for kdesdk its no big deal for them to create a kdesdk-libs
package that has the kompare-lib and the appwizard-library.

> 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?

+1 from my side. 

Andreas

-- 
You may worry about your hair-do today, but tomorrow much peanut butter will
be sold.