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
_______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
