[110506] trunk/dports/www/serf1

[Ryan Schmidt]

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.