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 18:22:09 CEST 2008
Am Dienstag, 6. Mai 2008, um 18:15 Uhr, schrieb Andreas Pakulat:
> On 06.05.08 17:56:11, Friedrich W. H. Kossebau wrote:
> > 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".
> Thats currently only a rule for kdelibs+kdepimlibs - AFAIK. Other
> modules in KDE/ need to decide on that themselves, for example kdegames
> broke BC in their libkdegames library between 4.0 and 4.1.
Was libkdegames public for 3rd-party development, i.e. have the headers been
> The techbase
> page explicitly says that the guidelines are not mandatory.
Which page is that?
More information about the release-team