breaking BIC for new addon libs in minor releases (was: Re: Goals? How are we doing?)
Friedrich W. H. Kossebau
kossebau at kde.org
Tue May 6 17:56:11 CEST 2008
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
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.
More information about the release-team