On Aug 31, 2013, at 18:44, Blair Zajac wrote:

> On 08/31/2013 04:36 PM, Ryan Schmidt wrote:
>> 
>> On Aug 31, 2013, at 18:33, Blair Zajac wrote:
>> 
>>> On 08/31/2013 04:30 PM, Ryan Schmidt wrote:
>>>> 
>>>> As I discussed in https://trac.macports.org/ticket/40155#comment:26, this 
>>>> patch changes things about the way serf1 builds -- it changes the 
>>>> compatibility version of the library from 4.0.0 to 1.3.1. This is probably 
>>>> not a good change to have made.
>>> 
>>> Besides having to recompile dependent ports, why wouldn't be a good change 
>>> to make?
>> 
>> Because the developers of serf have decided that serf 1.3.1 includes 
>> libserf-1 version 4.0.0. It's not our place in MacPorts to second-guess that 
>> and rebrand that library as version 1.3.1.
> 
> Well, I have an unaccepted invite to be a serf committer, so I don't know 
> where that places me on the statement on how to brand the library.  We're 
> discussing it here:
> 
> https://groups.google.com/d/msg/serf-dev/oljSQiKZ7YI/v8pwkqGf4psJ
> 
> The 4 comes from (MAJOR, MINOR, PATCH) = (1, 3, 1) with MINOR+1 for the 
> compatibility version for Mac's limitation that the X in X.Y.Z must be >= 0.  
> I disagree on how the 4.0.0 was computed, it should be 1.3.1, since the 
> version shouldn't ignore the major number, since technically, when serf 1.4.0 
> comes out, we would use a compatibility version of 5.0.0.  While OS X may 
> treat this as compatible, with the APR versioning system [1], this should be 
> treated as an ABI incompatible change, which it won't be.  So this change is 
> technically more accurate.
> 
> Blair
> 
> [1] http://apr.apache.org/versioning.html

If the library version number change is being made with the approval of the 
developers then of course that's fine. It's just weird when a library version 
number decreases. That should normally never happen.

Usually also the library version number is not tied directly to the package 
version number. There's no reason why they should be related. For example, 
libiconv 1.14 installs libiconv.2.dylib, compatibility version 8.0.0, current 
version 8.1.0. gettext 0.18.3.1 installs libintl.8.dylib, compatibility version 
10.0.0, current version 10.2.0.



_______________________________________________
macports-dev mailing list
[email protected]
https://lists.macosforge.org/mailman/listinfo/macports-dev

Reply via email to