BIC in libkonq

[Andreas Pakulat]

On 04.08.10 19:01:27, Modestas Vainius wrote:
> It's probably that the topic is not important or considered as not worth the 
> extra effort by majority of developers, so I don't expect situation to improve 
> greatly despite conclusion on k-c-d.

As I already said, the problem is not that developers don't care, they
simply don't know that a soname change is necessary (or they don't
know/understand when its necessary). You need to tell them (each and
every one) somehow, for example by putting something on techbase and
directing the developers in question (via their mailinglist) to the
place. They won't notice soname-problems themselves as they only have 1
version of the library installed which all apps link against.

> It's not me, you or release-team who can 
> fix all cases each release. What's more, I'm also afraid that when pushing too 
> hard people might start doing otherwise for the sake of extra safety - bump 
> soname in advance as soon as trunk opens without checking if changes are BC or 
> not. Tracking BC is not an easy task.

Right, tracking all BiC changes by reading commit logs is _extremely_
hard, especially in active projects. So IMHO its a valid way to simply
bump soname after a release. If you can't guarantee that your library is
BC between two releases (for whatever reason, including that its too
much work to track BiC changes, especially since there's no automated
way to do it), then the best you can do is bump the soname as soon as a
new development cycle starts.

Andreas

-- 
Your love life will be... interesting.