BIC in libkonq

[Maciej Mrozowski]

On Wednesday 04 of August 2010 18:01:27 Modestas Vainius wrote:
> 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.

It is not. It should be done by developers themselves when they introduce 
features, change code.

But.. such changes happen frequently in trunk (before next branching and after 
previous one) so developers would need to either bump SOVERSION every time 
they change ABI (hardly optimal, you'd end up with libplasma.so.50 early) or 
postpone SOVERSION bump just before tagging for all libraries with public 
interface that had their ABI changed. In the second case it's easy to forget 
about it.

Also developers usually don't have tools to reliably detect ABI changes - but 
disto devs sometimes do.

That being said, those equipped with sufficient tools - if possible - could 
run their tool just before tagging and list all libraries with public 
interface that need SOVERSION bump on kde-core-devel or kde-buildsystem ml 
(but that would mean the need to package RC's in Debian I suppose? no idea 
whether other distros have such means).

-- 
regards
MM
-------------- 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/b1bc95aa/attachment.sig