[110506] trunk/dports/www/serf1

Blair Zajac blair at orcaware.com
Sat Aug 31 16:44:25 PDT 2013


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



More information about the macports-dev mailing list