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. _______________________________________________ release-team mailing list [email protected] https://mail.kde.org/mailman/listinfo/release-team
