On Sat, May 29, 2010 at 11:17 AM, Koen Deforche <[email protected]> wrote:
> Hey Pau,
>
> 2010/5/29 Pau Garcia i Quiles <[email protected]>:
>> Hello,
>>
>> Wt 3.1.3 sets soversion 22 for all the libraries. What's the reason
>> for that? I have not looked into the changes but I'd say this would
>> have been more correct:
>
> I believe we had a discussion about this a few months ago, and then we
> concluded that whenever one library gets bumped, all dependent
> libraries should be bumped too. And then we can just as well bump them
> all to the same version. A soversion is just an integer, and so by
> "more correct" you mean that bumping all to the same number is bit
> onorthodox (just this once) and next time we will be "very correct" ?

Sorry for the delay in answering.

We discussed a related issue on (fake) IRC and private e-mails at the
end of March.

Back then, what we talked about was bumping soversion on dependent
libraries when dependee libraries were bumped. I. e. if you make
ABI-incompatible changes to libwt, you need to bump libwt soversion
and therefore, you need to bump libwthttp, libwtfcgi, etc.

But here is the catch (we did not talk about this): just not
necessarily bump all soversions to the very same soversion! In fact,
usually you do not want to have the same soversion for all libraries.

The point of soversions is stating binary compatibility. If you bump
the soversion of all libraries to the very same version, what will you
do when you make a change only in one of the libraries? Say in Wt
3.1.4 you make binary-compatible changes to libwt and libwthttp and
make binary-incompatible changes to libwtdbo and libwtsqlite. You do
not need to bump libwt, libwthttp, etc. In fact, you do not want to:
in that scenario, if my application only uses libwt, libwthttp and
libwtext, I can install Wt 3.1.4 and benefit from the bugfixes without
recompiling. If you bump all the soversion of all libraries (libwt,
libwthttp, libwtext, libwtdbo, etc) just because you made changes to
one of the leaves in the dependency tree, you do not get those
benefits for free: you are forced to recompile, even if it would not
be strictly necessary.

So my advice is:

  1) When you make binary-incompatible changes, bump soversion for
that library and all its dependent libraries. I. e. if you made
ABI-incompatible changes to libwt, you need to bump libwthttp,
libwtfcgi, etc (everything)

  2) Do not bump soversion unless it is needed. I. e. if you made
changes to libwtdbo but you did not make changes to any other library,
bump only libwtdbo* but do not bump the soversion of libwt,
libwtisapi, libwthttp, libwtfcgi and libwtext and libwtext

  3) Do not use the same soversion for all libraries. The moment you
hit case 2 above, you'll realize it does not make sense to have the
very same soversion for all libraries. In fact, if you were to use the
same soversion number, why bother having 8 different variables? :-)

If I knew a bit more about graphs and Boost::Graph I'd put together a
simple webapp to calculate this and suggest soversions

-- 
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)

------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
witty-interest mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/witty-interest

Reply via email to