breaking BIC for new addon libs in minor releases (was: Re: Goals? How are we doing?)

[Friedrich W. H. Kossebau]

Am Dienstag, 6. Mai 2008, um 17:17 Uhr, schrieb Andreas Pakulat:
> On 05.05.08 21:24:52, Andras Mantia wrote:
> > Actually would be nice to see at least a KDevPlatform release. I know
> > its hard, but maybe makes sense, just like kdelibs was released before
> > the actual KDE 4.0.0.
>
> Well, we could probably do that, but without any guarantees regarding
> binary compatibility. Especially not for the interfaces, shell, project,
> sublime, language and vcs libraries.

I have a similar problem. I know at least one person which would like to make 
use of the Okteta libraries (implementing a specialised ByteArrayModel) in a 
3rd-party project after the 4.1 release. But I know for sure the API will 
change for 4.2 again, so I do not install any headers. Right now I had to 
tell him "bad luck"...

I did not find an explicit rule for this on techbase.kde.org, just remember 
the general unwritten rule "ensure binary interface compatibility in minor 
releases".

Could this rule be made mandatory only for kdelibs and kdepimlibs?
So young and evolving libraries could follow the principle "release often and 
early" and get some more feedback, until they are mature enough to keep BIC 
till a next major release. Those interested to make use of such libraries 
would know of the risks and have a reason for still using them. Of course the 
API documentation should contain proper big warnings.

Friedrich