[PROJ] Motion: approve RFC3 update, and bump to C++17 for PROJ 9.6

[Alan Snow]

With PSC approval in PROJ thread, highlights in release notes, and updating
the compatibility in the documentation (especially the installation guide),
I think that will help communicate the change.

>From the perspective of pyproj & manylinux wheels, having a warning and
compatibility information will be helpful.

+1 to the amendment to RFC3

On Tue, Jan 7, 2025, 1:55 AM Kristian Evers <kristianevers at gmail.com> wrote:

> I think we can do a little bit of fine-tuning. I’ve added an extra commit
> to the branch with my additions:
>
>
> https://github.com/OSGeo/PROJ/pull/4369/commits/8f045bac73d2823d1d3ee17b3537b5d58d902995
>
> I’ve clarified that a change in version requirements needs to be
> communicated clearly and removed a line
> about changing versions of programming languages that contradicts the
> reason why we are updating this RFC
> In the first place.
>
> With those details added I am +1 as well.
>
> /Kristian
>
> On 7 Jan 2025, at 04.48, Even Rouault via PROJ <proj at lists.osgeo.org>
> wrote:
>
>
> Le 07/01/2025 à 04:37, Alan Snow a écrit :
>
> At first glance, it seems reasonable. Though I have a couple of questions
> for clarification.
>
> Would it make sense to word the RFC so we prefer making dependency changes
> on major releases, but exceptions can be made? For example, if the
> dependency charge can be classified as a minor change and will cause
> minimal disruptions, then an exception can be made.
>
> What were the reasons for originally wanting to only apply dependency
> updates for major releases? How do we plan to ensure the original reasons
> are not overlooked for minor releases?
>
>
> IMHO spending more time fine-tuning RFC-3 is not worth it. Our usual
> communication mechanisms, pull requests or messages on this list, and
> seeking for enough consensus, and making a motion if needed, are enough to
> handle those situations.
>
> --
> http://www.spatialys.com
> My software is free, but my time generally not.
> Butcher of all kinds of standards, open or closed formats. At the end,
> this is just about bytes.
>
> _______________________________________________
> PROJ mailing list
> PROJ at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/proj
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20250107/7c7f50df/attachment.htm>