Even Rouault <even.roua...@spatialys.com> writes: [I'm behind in dealing with gdal, but otherwise would be in the same boat as Bas]
> There has been obviously a misunderstanding. The rule we follow is that: > - between GDAL X.Y.Z and X.Y.(Z+1), both C and C++ ABI are stable > - between GDAL X.Y and X.(Y+1), the C ABI is stable, but the C++ one not That's a perfectly ok policy. > And this is what we have in our release procedure: > """ > 4) Update LIBGDAL_CURRENT/REVISION/AGE macros in GDALmake.opt.in. > - For a release with no interface changes just bump REVISION. > - Adding interfaces, bump CURRENT/AGE, set REVISION to 0. > - Deleting interfaces / compatibility issues - bump CURRENT, others to > zero. > """ 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. > So as interfaces were added, I bumped CURRENT/AGE and set REVISION to 0. > But maybe "compatibility issues" should also be understood to changes that > affect the C++ > ABI ? > > 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. Even better would be to keep the C++ ABI stable. I'm not really clear on the details here, but it seems that C++ and stable tend not to go together, and I have heard people (not necessarily here) express that it is too hard to know if the C++ lib ABI has changed or not. _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
