libkonq and ABI stability

[Aaron J. Seigo]

On February 3, 2010, Thiago Macieira wrote:
> Em Terça-feira 2. Fevereiro 2010, às 23.53.14, Andreas Pakulat escreveu:
> > This one is easy. If the answer to a) is "we don't guarantee ABI compat
> > for the KDE4 lifetime of libkonq", then increasing the SOVERSION is
> > enough to warrant any ABI change. Apps in extragear and outside of
> > svn.kde.org will simply use the old version until they switch to the new
> > one. Distro's can install both version side-by-side (due to the
> > different SOVERSION) without any trouble.
> 
> They have to build Konqueror twice (in fact, the whole kdebase-apps) in
> order to get both versions of libkonq.
> 
> The distros won't like it, but it's doable.

that's why i assumed that it isn't realistic to do so right immediately. i 
think it would be more pain than really needed, and it isn't so critical to 
get the symbol count down in this library as to be overly aggressive about it.

however, it might be workable to deprecate the classes now[1] and schedule the 
for removal after a certain period of time. e.g. if we said 'these two classes 
will go away by KDE SC v4.8" and then went around cleaning up our own code in 
svn.kde.org, this would give us enough time to avoid the problem on having two 
versions of kdebase-apps to package assuming those apps have a release 
themselves in the next 2 years.

that would avoid us waiting until if/when KDE5 happens to do so.

[1] they are already labeled as deprecated in the CMakeLists.txt file, but 
aren't marked as deprecated in the C++ header files.

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks