Bump soname version in case of API/ABI breakage

[volter]

According to upstream-tracker.org, there were a number of API/ABI breaks in the past. Such changes should be reflected by changing soname versions.

This is a major concern for packagers.

 http://upstream-tracker.org/versions/gdal.html

[rouault]

Bumping soname is done. Could you be more specific of a case where it wasn't done and should have be done ???

[opoplawski]

See the link provided, it lists the abi breaks. I also don't see that the soname has been updated.

[warmerdam]

An interesting tool, which shows we have been exposing some things in the ABI unintentially. Nevertheless, I do not consider some of those things breaks in the ABI as I care about it.

Note, we generate the soname using libtool and we (within our definition of the public ABI) bumb the current/revision/age values from release to release. See the gdal/HOWTO-RELEASE for details on how we do this.

It is not entirely clear to me what packaging problems this is causing. I'm guessing you are speaking from the point of view of ELGIS?

[opoplawski]

I can't speak to what part of the ABI are public or private, but there were certainly changes to the code that if programs used that code and were linked to an earlier version of the library and then the library was upgraded that it could cause failures. I would have said that from the report the changes from 1.8.1 to 1.9.0 would have merited bumping LIBGDAL_CURRENT (a number of removed symbols and changes to existing symbols).

The packaging problem come in when deciding what version updates can be pushed to older releases and when programs that use gdal need to be recompiled or will still be compatible with the new version.