[gdal-dev] GDAL 3.1.0 RC2 available

[Sebastiaan Couwenberg]

On 5/3/20 9:15 PM, Even Rouault wrote:
> Answering Bas'
> 
>> If you don't want that, then two libraries need to be built with their
>> own library versioning.
> 
> and Gregs'
> 
>> This doesn't make sense.  The current/revision/age needs to be handled
>> differently for the C library and the C++ library, because in feature
>> releases one of them does not have an ABI break and the other one does
>> have an ABI break.  They will then not have the same shlib major
>> numbers, which is an obvious consequence of the above versioning policy.
> 
> Separating a C library from a C++ one would represent a big deal of work, as there are C 
> symbols called from C++ code, so that means that when currently there's a C function like 
> GDALInvGeoTransform(), there should be a C++ one, like gdal::InvGeoTransform() that does 
> what GDALInvGeoTransform() does, and GDALInvGeoTransform() would call this one, and 
> make sure all code from drivers etc that calls currently GDALInvGeoTransform() would call 
> instead gdal::InvGeoTransform().
> Anyway this isn't a discussion for this release, but more for a GDAL 4 or more.
> 
>>> I'm not sure about the resolution here. Should I do a RC3 that sets
>>> CURRENT/REVISION/AGE to 27/0/0 ? Would that help ?
>>
>> I think it would be really unfortunate to break the C ABI as a side
>> effect.  That would change your policy above that there is (perhaps) an
>> ABI break on feature releases.
> 
> The C ABI of GDAL 3.1 is the same as GDAL 3.0. But if I bump the CURRENT number, as there's 
> just one lib, it will apply to the C and C++ side of it obviously. So I can imagine that's slightly 
> inconvenient for people that just depend on the C ABI and wouldn't need to rebuild, but I'm 
> afraid there's no way to make everybody happy.

It's indeed not possible to make everybody happy, so the question is who
you do mind the least to make unhappy.

If nothing changes packagers like me will be unhappy because they need
to reintroduce the virtual dependency for the unstable C++ ABI.

C-only users will be unhappy about having to rebuild their code when the
only C++ ABI breaks.

And you will be unhappy if you have to split the library.

Bumping the SONAME for C++-only ABI breaks is the most correct solution
as long as its provided by the same library, and splitting the libraries
in GDAL 4 seems like the right thing to do.

The choice is up to you.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1