[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