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

Andreas Pakulat apaku at gmx.de
Tue May 6 19:52:52 CEST 2008


On 06.05.08 19:01:15, Tom Albers wrote:
> Op dinsdag 06 mei 2008 18:46 schreef u:
> > Am Dienstag, 6. Mai 2008, um 18:39 Uhr, schrieb Tom Albers:
> > > Op dinsdag 06 mei 2008 18:30 schreef u:
> > > > > I disagree. I think it is a must to be BC between minor releases.
> > > > > If you want to be bic && public, go to extragear/libs untill you are
> > > > > ready...
> > > >
> > > > What would this change for 3rd-party developers?
> > >
> > > You can make a release whenever you like and bump the major so version of
> > > the lib as you like in each release.
> > 
> > That would be me, but I asked for 3rd-party developers.
> > Then, I know I would not make releases independent of the KDE ones, because I 
> > would develop the libs and the program together. So nothing would change for 
> > 3rd parties, just another location.
> 
> The difference is that you have a proper versioning with library version numbers. 3rd party devels can check for that and adapt their code to those versions. 

What has library versioning to do with keeping BC? If a lib breaks BC it
increases its so version and can also adjust its major version number.
The library doesn't have to follow the global KDE version number at all,
for example the kdevplatform libs don't do it for the plain reason that
its not very honest to say they are version 4.x. That version would
indicate a matureness the library simply doesn't have.

> I like to keep minor release from KDE BC and more importantly 3rd party devels should be able to rely on that.

Right, people using a lib need to rely on that lib keeping BC within a
major version, that doesn't mean a library can't change BC between
releases, it just means it needs to increase its major version. And if
the library devs want to release it with KDE and have it as KDE module
thats fine too - IMHO.

Andreas

-- 
You are a fluke of the universe; you have no right to be here.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://mail.kde.org/pipermail/release-team/attachments/20080506/5a7a321e/attachment.pgp 


More information about the release-team mailing list