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 18:18 Uhr, schrieb Tom Albers:
> Op dinsdag 06 mei 2008 17:56 schreef u:
> > 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".
>
> From the policies section:
> http://techbase.kde.org/Policies/Binary_Compatibility_Issues_With_C++
> "In the KDE project, we will provide binary compatibility within the
> life-span of a major release."

Ah, overread it there, thanks. The name "Binary_Compatibility_Issues" does not 
sound too much like a place for promises to 3rd-party developers :)

> > 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.
>
> I disagree. I think it is a must to be BC between minor releases.

For everything?

> If you want to be bic && public, go to extragear/libs untill you are
> ready...

What would this change for 3rd-party developers? For me it would be more work, 
as I would have development spanned between extragear/libs and kdeutils. And 
it would add an additional (if only soft) dependency between modules. 

Friedrich