[PROJ] PROJ 9.0.0RC1 & PROJ-data 1.9RC1

[Even Rouault]

Le 17/02/2022 à 10:35, Kristian Evers via PROJ a écrit :
> Thanks for the thorough explanation, Bas. It's much appreciated!
>
> Even, Mike: I haven't got strong opinions on this. Do you guys think it is
> worth the hassle to switch to the model Bas describes here?
I also don't have a strong opinion. One advantage is that it makes it 
more obvious which PROJ version the lib is. The only potential issue I 
can imagine is that if some day we have a PROJ 22.2.1 version installed 
together with PROJ 8.2.1, they would both be libproj.so.22.2.1, but 
that's probably mostly a theoretical concern...
>
> /Kristian
>
>> -----Original Message-----
>> From: PROJ <proj-bounces at lists.osgeo.org> On Behalf Of Sebastiaan
>> Couwenberg
>> Sent: 16. februar 2022 12:38
>> To: proj at lists.osgeo.org
>> Subject: Re: [PROJ] PROJ 9.0.0RC1 & PROJ-data 1.9RC1
>>
>> On 2/16/22 09:35, Kristian Evers via PROJ wrote:
>>> Bas, I'm not sure how to understand this.
>>>
>>>> So you go from (8.2.1):
>>>>
>>>>     /usr/lib/x86_64-linux-gnu/libproj.so -> libproj.so.22.2.1
>>>>     /usr/lib/x86_64-linux-gnu/libproj.so.22 -> libproj.so.22.2.1
>>>>     /usr/lib/x86_64-linux-gnu/libproj.so.22.2.1
>>>>
>>>> To (9.0.0):
>>>>
>>>>     /usr/lib/x86_64-linux-gnu/libproj.so -> libproj.so.9.0.0
>>>>     /usr/lib/x86_64-linux-gnu/libproj.so.25 -> libproj.so.9.0.0
>>>>     /usr/lib/x86_64-linux-gnu/libproj.so.9.0.0
>>>>
>>> Are you suggesting that we ONLY use the major, minor and patch version
>>> numbers for the so-files and forget about the SOVERSION from now on?
>> No, SOVERSION is essential as it is part of the SONAME:
>>
>>    <NAME>.so.<SOVERSION>
>>
>> Where <NAME> = libproj, and <SOVERSION> = 25
>>
>>> If that is the case, personally I'm all for it since I've always found the
>>> current/revision/age difficult (as is evident in several release candidates
>>> in the past) but is that a common practice among project that base their
>>> packages on CMake?
>> autotools determines the versions (both 22 and 22.2.1 in the above
>> examples for 8.2.1 with version-info 24:1:2) based on the version-info.
>>
>> SOVERSION (the 22 in libproj.so.22) is determined by CURRENT minus AGE,
>> the filename version (22.2.1 in libproj.so.22.2.1) is determined by
>> (CURRENT-AGE).AGE.REVISION or some other magic.
>>
>> The SOVERSION cannot be decremented and must be incremented every
>> release that breaks the ABI. This was 22 in 8.2.1, is currently 25 in
>> 9.0.0-rc1, and could also be 23 in 9.0.0-rc2.
>>
>> You configure this in CMake with:
>>
>>     set_target_properties(proj
>>       PROPERTIES
>>       VERSION <X>.<Y>.<Z>
>>       SOVERSION <N>
>>     )
>>
>> This creates the files:
>>
>>    libproj.so             (symlink to libproj.so.<X>.<Y>.<Z>)
>>    libproj.so.<N>         (symlink to libproj.so.<X>.<Y>.<Z>)
>>    libproj.so.<X>.<Y>.<Z>
>>
>> Now that autotools and libtool are no longer used, you don't have to use
>> the complicated logic to determine the VERSION value (<X>.<Y>.<Z>).
>>
>> For projects that start with CMake and only support that it's common to
>> use the project major version for the SOVERSION value and full project
>> version for VERSION value.
>>
>> That cannot be used for PROJ as it is migrating away from autotools and
>> cannot decrement the SOVERSION to 9.
>>
>> This situation is similar to what MapServer did some time ago, that
>> currently uses:
>>
>>     set_target_properties(mapserver
>>       PROPERTIES
>>       VERSION ${MapServer_VERSION_STRING}
>>       SOVERSION 2
>>     )
>>
>> This is what I also suggest for PROJ to make library versioning easier
>> now that the libtool complications are gone.
>>
>> Since code speaks louder than words, see the attached patch for an
>> example of what I mean.
>>
>> Kind Regards,
>>
>> Bas
>>
>> --
>>    GPG Key ID: 4096R/6750F10AE88D4AF1
>> Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1
> _______________________________________________
> PROJ mailing list
> PROJ at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/proj

-- 
http://www.spatialys.com
My software is free, but my time generally not.