<div dir="auto">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.<div dir="auto"><br></div><div dir="auto">From the perspective of pyproj & manylinux wheels, having a warning and compatibility information will be helpful.</div><div dir="auto"><br></div><div dir="auto">+1 to the amendment to RFC3</div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Tue, Jan 7, 2025, 1:55 AM Kristian Evers <<a href="mailto:kristianevers@gmail.com">kristianevers@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="">I think we can do a little bit of fine-tuning. I’ve added an extra commit to the branch with my additions:<div><br></div><div style="display:block"><a href="https://github.com/OSGeo/PROJ/pull/4369/commits/8f045bac73d2823d1d3ee17b3537b5d58d902995" target="_blank" rel="noreferrer">https://github.com/OSGeo/PROJ/pull/4369/commits/8f045bac73d2823d1d3ee17b3537b5d58d902995</a></div><div style="display:block"><br></div><div style="display:block">I’ve clarified that a change in version requirements needs to be communicated clearly and removed a line</div><div style="display:block">about changing versions of programming languages that contradicts the reason why we are updating this RFC</div><div style="display:block">In the first place.</div><div style="display:block"><br></div><div style="display:block">With those details added I am +1 as well.</div><div style="display:block"><br></div><div style="display:block">/Kristian</div><div><div><br><blockquote type="cite"><div>On 7 Jan 2025, at 04.48, Even Rouault via PROJ <<a href="mailto:proj@lists.osgeo.org" target="_blank" rel="noreferrer">proj@lists.osgeo.org</a>> wrote:</div><br><div><div><br>Le 07/01/2025 à 04:37, Alan Snow a écrit :<br><blockquote type="cite">At first glance, it seems reasonable. Though I have a couple of questions for clarification.<br><br>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.<br><br>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?<br></blockquote><br>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.<br><br>-- <br><a href="http://www.spatialys.com" target="_blank" rel="noreferrer">http://www.spatialys.com</a><br>My software is free, but my time generally not.<br>Butcher of all kinds of standards, open or closed formats. At the end, this is just about bytes.<br><br>_______________________________________________<br>PROJ mailing list<br><a href="mailto:PROJ@lists.osgeo.org" target="_blank" rel="noreferrer">PROJ@lists.osgeo.org</a><br><a href="https://lists.osgeo.org/mailman/listinfo/proj" target="_blank" rel="noreferrer">https://lists.osgeo.org/mailman/listinfo/proj</a><br></div></div></blockquote></div><br></div></div></blockquote></div>