ptlib transition

[Eugen Dedu]

Mark Purcell wrote:
> On Monday 30 March 2009 20:53:59 Eugen Dedu wrote:
>> Adeodato Simó wrote:
>>> Naming the development package without version information (libpt-dev)
>>> is great, so thanks for that.
>> Could someone explain why libpt-dev is so interesting compared to
>> libpt2.6.1-dev?  The problem is that each new ptlib version will be
>> incompatible with any other version, so each new ptlib version will lead
>> to a rebuild of all its rdeps, and to a FTBFS too...
> 
> Eugen,
> 
> A couple of issues:
> 
> Not every version breaks API compatibility, a break in ABI compatibility can 
> be fixed with a rebuild of rdeps, but only if a common -dev file is used. 
> Source packages for each and all rdepends don't need to be reloaded. This is 
> what we propose. This makes for good upstream development and long term 
> support. Something we want to support.
> 
> A break in API compatibility presents more issues and does present FTBFS for 
> rdeps.  This isn't good upstream practice as it requires fixes to the source 
> code for all rdeps. 
> 
> popcon has an installed base of some 20,000 users with libpt-1.10.10, which is 
> a old and unsupported lib but we have a few rdepends that haven't keep pace 
> with the API changes. Thus we can't move on ;-( By making a common -dev 
> package this forces the issue, bugs get filed against FTBFS and packages which 
> don't keep up can be dropped.

Hi Mark,

Thanks for information.  So opal and ekiga will depend on libpt-dev (>= 
2.6.1) from now on, is that right?

> How does ekiga work around the changes in API, are ekiga releases closely tied 
> with ptlib releases?

Yes, they (ptlib, opal and ekiga) are closely tied together.  You do not 
need to worry about ekiga, I will release it each time ptlib/opal are 
released.

> Some interesting documents about the subject:
> Preserving Backward Compatibility http://www.onlamp.com/lpt/a/5626
> Parallel Installation http://www106.pair.com/rhp/parallel.html

Thanks!

-- 
Eugen