4.0 -> 4.1 binary compatibility

[Leo Savernik]

Am Donnerstag, 25. Oktober 2007 schrieb Andreas Pakulat:
> > > Um, no. Only if they want to uninstall 4.0, they would have to remove
> > > all things which depend on 4.0.
> >
> > So the plan is to have two kdelibs installed, a 4.0 one and a 4.1 one?
>
> There is no plan. Also that would be impossible with the current state
> of things because both would have files that have the same installed
> path. So you'd either also need to remove all binaries in kdelibs to
> someting like foo41 or install kdelibs 4.1 into a separate prefix and
> not /usr.

No, it's even worse. Pretended that libkfoo-4.0.0 released under KDE 4.0 is 
BICed, you have to bump the soname to libkfoo-5, and consequentially release 
a libkfoo-5.0.0 for KDE 4.1. However, as we have to stay binary compatible 
for the whole major release series, we have to *retain* libkfoo-4.0.0 for all 
binary clients linked against libkfoo-4.0.0.

This effectively means, we have to maintain *two* variants of the library 
libkfoo for the whole lifetime of KDE 4, one compat libkfoo-4.0.0 and one 
"real" libkfoo-5.x.y where all new development takes place.

Who is going to perform the maintenance of compatibility library variants? Who 
is going to ensure that libkfoo actually continues to fulfill the interface 
contracts it fulfilled in KDE 4.0? Will two copies of libkfoo's source be 
maintained, one legacy, one recent? Will libkfoo-4 be made a small wrapper 
around libkfoo-5 and who is going to maintain that? Who is going to prepare 
the build system?

It's a nightmare if consequently thought to an end. Therefore, we'd better 
avoid it at all costs.

mfg
	Leo