Re: transition: proposal libpt2.6.5->libpt2.6.6 & libopal3.6.6->libopal3.6.7
On 24/04/10 2:56 PM, Mark Purcell wrote:
This issue is common with C++ libraries. The second part ofsSection 3.6
of the following page (which you also reference above) does
On Saturday 24 April 2010 13:26:20 Craig Southeren wrote:
As one of the maintainers of the upstream (opal& ptlib), please feel
free to email me if I can help
Thanks for the offer.
I do have one question/ request of upstream.
Does the soname for ptlib/ opal need to change with every release?
Generally this isn't considered best practise:
Are subsequent minor versions of the libs really not binary (ABI) compatible?
The problem for distributions is that every time the soname changes all depends of
that library then need to be rebuilt and everyone needs to download all of the
rebuilt binary packages.
In contrast if the soname is only bumped when binary compatibility is broken then
we only need to rebuild as necessary.
In this particular case I wouldn't need to coordinate the transition from ptlib
2.6.5 -> 2.6.6 as I suspect they are binary compatible.
a good job of describing the issues
Given these constraints, and with an API as rich and complex as Opal and
PTLib, binary compatibility between revisions is not something we strive
However, we do try very hard to maintain source compatibility across
minor revisions. An API change that would break comptibility in a big
way is usually a trigger
for a new major revision.
I hope this gives some insight into our thinking
Craig Southeren Post Increment ñ VoIP Consulting and Software
Phone: +61 243654666 ICQ: #86852844
Fax: +61 243656905 MSN: email@example.com
Mobile: +61 417231046 Jabber: firstname.lastname@example.org
"Science is the poetry of reality." Richard Dawkins