[gdal-dev] libtool numbering policy

[Even Rouault]

Le mardi 14 juin 2016 14:16:51, Greg Troxel a écrit :
> Even Rouault <even.rouault at spatialys.com> writes:
> > A ticket ( https://trac.osgeo.org/gdal/ticket/6542 ) has been raised
> > about libtool SONAME having not changed between GDAL 2.0.X and GDAL
> > 2.1.0 due to incrementing both LIBGDAL_CURRENT and LIBGDAL_AGE .
> > This was raised also in https://trac.osgeo.org/gdal/ticket/4543
> > 
> > Our, more or less implicit, policy up to now was to take just into
> > account the C ABI, and not the C++ one. Any opinion if we should change
> > it to take into account the C++ ABI as well ?
> 
> I can see the point, but the other half of the situation is that
> packages do (or should) make a significant effort not to have ABI
> changes.  With C ABIs, that seems to work pretty well.   I have the
> impression that C++ ABIs are much more unstable, and they also seem to
> change in practice when changing compilers.  So I am left wondering how
> much stability benefit there really is for C++ by adopting such a
> change.
> 
> Would you expect a C++ ABI change every release? 

Except for bugfixes releases, in practice yes for the yearly "feature" release 
("feature" meaning here a change of major or minor in the "GDAL 
major.minor.micro" scheme), as adding a new capability / virtual method, or a 
new optional parmeter, etc... changes the C++ ABI.

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com