BIC in libkonq

[Modestas Vainius]

Hello,

On trečiadienis 04 Rugpjūtis 2010 15:09:32 Lubos Lunak wrote:
> fact exactly the opposite. They both state that some libraries, by design,
> do not keep binary compatibility, and that when a change happens, soname
> should be changed.

The latter is exactly my point. libkonq 4.5 is BIC in comparison with libkonq 
4.4 and soname was NOT bumped (when should have). So what is opposite there to 
my arguments?

> > In this case, our arguments were apparently discarded because "making an
> > exception for libkonq doesn't make that much sense".
>  
>  "to me" is missing at the end of that sentence. And, while I'm at it, the
> consequent "any other opinions?" is missing too.

Do I decide what ends up in tarballs? No. Things which do not make much sense 
are typically not done. So conclusion is that nothing would have been done wrt 
kdebase.

Given that there is still a week until 4.5.0, we may find all those BIC cases 
and fix them in 4.5 by bumping soname where needed. Would there be any 
objections to that? I think this question is on-topic for release-team ML.

> > I admit it may be a
> > bit late as we do not package pre-releases nowadays (which may be our
> > fault but that's the way it is for now). Therefore, I cannot be in
> > supervisor position for these things until it is "too late" nor anybody
> > would listen to me.
> 
>  Oh, poor you. But in case you'll get over this attitude and will be
> interested in fixing the problem, you've been told where the right place to
> discuss the problem is.

Thank you for suggestion. Maybe I will try again. Though even if you do not 
agree, this has already been brought up on that list a couple of times before 
and I can't say that situation has improved much over time. Yes, libkonq has 
not broken BC during 4.x cycle before, but many others non-kde(pim)libs did. 
In neither case soname was bumped with a good exception of libplasma when it 
was in workspace and moved to kdelibs (libplasma.so.{1,2,3}).

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. 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.

-- 
Modestas Vainius <modestas at vainius.eu>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/release-team/attachments/20100804/ccbe7e4d/attachment.sig