[gdal-dev] GDAL 3.1.0 RC2 available

[Even Rouault]

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.

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

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20200503/33c8c500/attachment.html>