Interestingly for GDAL there was no mayor release needed (or we did not realize it).
Something that is not discussed is if the new features of C++17 can be used in the API, or only in internally in the implementation. In a GDAL PSC meeting we decided the latter (no C++17 new features in the C++ API, but I do not remember if it was written anywhere). I am fine with both, update to C++17, and change RFC3 if needed. On Mon, 6 Jan 2025 at 16:31, Kristian Evers via PROJ <proj@lists.osgeo.org> wrote: > Here’s a few excerpts from RFC3: > > A change in programming language standard can only be introduced with a > new major version release of PROJ > > > That means that a change to C99 is possible, as long as the PROJ PSC > acknowledges such a change. > > > When a new standard for either C or C++ is released PROJ should consider > changing its requirement to the next standard in the line. For C++ that > means a change in standard roughly every three years, for C the periods > between standard updates is expected to be longer. Adaptation of new > programming language standards should be coordinated with a major version > release of PROJ. > > > The first excerpt says we can’t make this change until PROJ 10.0.0 is > released. The second excerpt states that the PSC should acknowledge a > change in which version of either C or C++ is used. And the last encourages > us to reconsider the dependencies once in a while. These may not go > particularly well together and were written at a time where we did rather > frequent major version updates. So maybe a first step is a revision to RFC3 > so it allows os to change the minimum version of C and C++ without a major > version release of PROJ. It could easily be a number of years before we go > to PROJ 10. > > What do you guys think? Is the current version of RFC3 too strict? > > /Kristian > > On 6 Jan 2025, at 16.15, Kurt Schwehr via PROJ <proj@lists.osgeo.org> > wrote: > > I take RFC 3's text as meaning that there doesn't need to be a vote with > this switch, but that it's a nice thing for the person doing the update to > let the list know of the change happening. If the project wants to switch > to C++23, that would imply that a motion is needed. > > If that's different from peoples' expectations, we should definitely > discuss. > > If it were a motion, I'd definitely +1 for C++17. > > On Mon, Jan 6, 2025 at 6:49 AM Howard Butler via PROJ < > proj@lists.osgeo.org> wrote: > >> >> >> > On Jan 2, 2025, at 5:54 PM, Even Rouault via PROJ <proj@lists.osgeo.org> >> wrote: >> > >> > Hi, >> > >> > Happy New Year! >> > >> > I propose we update our build requirement from C++11 to C++17. This >> should hopefully be unnoticed by anyone using a not too antiquated build >> chain. >> > >> > Initial trigger for this move is explained in >> https://github.com/OSGeo/PROJ/pull/4366. All our existing CI >> configurations already satisfy the C++17 requirement (and one of them was >> already testing C++20 compatibility) >> > >> > I don't anticipate much use of new capabilities for now except perhaps >> replacing our internal::make_unique<> by C++14 std::make_unique<> >> > >> > C++17 has been a build requirement for GDAL since one year and nobody >> complained. Cf >> https://gdal.org/en/stable/development/rfc/rfc98_build_requirements_gdal_3_9.html >> for an analysis of the impacts. >> > >> > This also satisfies https://proj.org/en/stable/community/rfc/rfc-3.html >> which mentions "Keeping a policy of always lagging behind be two iterations >> of the standard is thought to be the best comprise between the two >> concerns", given that C++20 and C++23 are out. >> >> >> Is this a PSC motion? +1 :) >> >> Howard >> _______________________________________________ >> PROJ mailing list >> PROJ@lists.osgeo.org >> https://lists.osgeo.org/mailman/listinfo/proj >> > _______________________________________________ > PROJ mailing list > PROJ@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/proj > > > _______________________________________________ > PROJ mailing list > PROJ@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/proj >
_______________________________________________ PROJ mailing list PROJ@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/proj
