Hermann,
I dare to say that, if we are following this path, maybe GDAL should start marketing itself as a set of command line tools and not as a library, given that breaking compatibility just because we can is not something a library developer should do, IMHO.
I believe your words aren't reflecting the reality. We don't break things just to annoy people or because we can. We do it when we estimate it is in the best interest of the GDAL code base and its users, in the long term. There are adaptation costs for each side that can certainly felt as painful in the short/near term. That's life. There are past choices that turn out to be not ideal 15 years later down the road.
Regarding silent breakage, just have a look at https://gist.github.com/rouault/9d58bee0ceea111bd9913a03c9f13331 which shows an interesting change of behavior between C++03 and C++11. Or Python 2 vs Python 3 ( 2 / 3 = 0 vs 2 / 3 = 0.666667 ), or ... put it very long list here of software with long existence and that try to adapt themselves to remain relevant for their users and maintainable for their contributors ...
That said, https://github.com/OSGeo/gdal/pull/6722 should help addressing your concerns about silent breakage.
Even -- http://www.spatialys.com My software is free, but my time generally not. _______________________________________________ gdal-dev mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/gdal-dev
