Daniel, > It's not clear to me that the benefits of the C++11 requirement justify > the potential trouble for those who have to support platforms with older > compilers.
I can understand your concerns, and I would personnaly have been fine with sticking with oldish C++ as well, but we must also take into account the appealing of the project environment to other developers for its long term viability. > I do care about portability, it was one of the founding > principles of the project 20 years ago and I do not think that "stick to > GDAL 2.2" is an acceptable answer to the portability question. The fact > that other SDKs or apps may have the C++11 requirement is also not a > justification in my mind either for a core piece as important as GDAL. If you look at Linux platforms that have not a default C++11-ready compiler (ie gcc < 4.8) and are still security maintained, I don't think there are that many. In Ubuntu world, 12.04 is no longer security maintained since April or May this year. And 14.04 old-LTS has GCC 4.8 Debian old-old-stable wheezy has gcc 4.7 but will be end-of-life May 2018, so when GDAL trunk will be released. Debian old-stable jessie has gcc 4.9, so it is fine. RHEL/Centos 6 with gcc 4.4 and its super long support cycle is probably the only Linux distro that don't have the requirements out-of-the-box and still be security maintained at the time GDAL trunk is released. Supporting old platforms means also supporting old versions of various dependencies. I do not really see a lot of funding coming for those activities, perhaps because people get it for free in all meaning of the term, like most maintainance tasks. If people really need to have recent GDAL on old platforms, they can use backported toolchains, hire developers to backport the features they need to older branches, etc... Even -- Spatialys - Geospatial professional services http://www.spatialys.com
_______________________________________________ gdal-dev mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/gdal-dev
