[gdal-dev] GDAL 3.1.0 RC2 available

[Greg Troxel]

Even Rouault <even.rouault at spatialys.com> writes:

> 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.

If the ABI changes you have to bump the shlib major.  Or, you have to
have some special, irregular rule, that says the C++ ABI is unstable
despite the shlib staying the same, or a special rule that says the C++
ABI is private and may not be used.

>> > 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.

This is the nature of using C++ :-(

>> Even better would be to keep the C++ ABI stable.
>
> Not doable. Sometimes you need to add a new virtual method for exemple, like was done for 
> 3.1.


At least for this relase, there should be a paragraph in NEWS that very
clearly explains the API/ABI change situation with respect to previous
releases and whether shlib majors have changed, and any deviations from
norms.  Maybe that's there, but Bas seemed surprised by this.  I admit
that I don't usually see this, but I think statements of API/ABI compat
belong in NEWS and should be super clear.