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 > <mailto:proj@lists.osgeo.org>> wrote: >> >> >> > On Jan 2, 2025, at 5:54 PM, Even Rouault via PROJ <proj@lists.osgeo.org >> > <mailto: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 <mailto: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
