<div dir="ltr"><div>Hi everyone</div><div><br></div><div>Thanks for all the feedback. <br></div><div><br></div><div>In practical terms then, shall we:</div><div>- remove all python references from the Language Standards draft RFC [0] and vote only for C/C++, while creating a separate RFC for the minimum python version? <br></div><div>- add a formula that sets on which pace the minimum supported python version will change to the Language Standards draft RFC [0] and vote for everything altogether? <br></div><div><br></div><div>Vero<br></div><div><br></div><div>[0] <a href="https://trac.osgeo.org/grass/wiki/RFC/7_LanguageStandardsSupport">https://trac.osgeo.org/grass/wiki/RFC/7_LanguageStandardsSupport</a></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">El mar, 2 mar 2021 a las 22:54, Markus Neteler (<<a href="mailto:neteler@osgeo.org">neteler@osgeo.org</a>>) escribió:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi all,<br>
<br>
On Tue, Mar 2, 2021 at 8:15 AM Nicklas Larsson via grass-dev<br>
<<a href="mailto:grass-dev@lists.osgeo.org" target="_blank">grass-dev@lists.osgeo.org</a>> wrote:<br>
><br>
> Good, Anna, you brought up this question on regular update of Python version support. I deliberately left that part out of the draft for setting/updating language standards, as I would argue it deserves a RFC on its own.<br>
<br>
I agree to both:<br>
<br>
- we need to find a formula with our release rhythm and the oldest<br>
still supported Python version,<br>
- and yes, please let's separate this out into a different discussion<br>
(RFC if needed).<br>
<br>
I.e., one C/C++ RFC and one Python RFC.<br>
<br>
> A RFC should't be updatable, but may be overridden, partly or completely, with a new RFC. Adopting adherence to a new C or C++ standard will most likely be a quite rare business and should be dealt with a new RFC.<br>
<br>
I agree to that, as it would become a moving target otherwise.<br>
<br>
> The discussed approach, following the Python versions life-cycle, could possibly look a little different, however the forms and modes for this should be established likewise with a RFC.<br>
><br>
> If we agree now, to set Python 3.6 as a minimum, we have roughly six months to work out such a procedure. I’m glad to assist to this in, say around, October, in time for the 3.6 retirement.<br>
<br>
Let me suggest to separate Python out into another discussion.<br>
The pace of C/++ standards and that of Python versions are quite<br>
different and not easy to handle in a single RFC.<br>
<br>
Just my 0.02 cents,<br>
<br>
Markus<br>
</blockquote></div>