<div>                First of all, thank you all for your feedback and contribution to this topic. I think it is really important to clearly state the "rules of the game" for going forward.<br><br>Let me try summarise the need for this:<br><br>- There is no official, clear statement on C standard support for the project<br>- The implicit understanding of adherence to C89/C90 is no longer correct, as the code base contains C99 additions.<br>- Newer C standards (C99 and later) may provide better cross platform support and safer code.<br>- G7 has seen the transition from Python 2 to 3 [1]. Going forward, a final (official and unambiguous) dot for Python 2 need to be put with a statement of minimum support of a Python 3 version.<br>- Only a small part of the code base is consists of C++ [2]. To the best of my knowledge there in not even an implicit understanding/agreement on standard support.<br>- Platform and compiler support of the standards has improved notably in recent years.<br><br><br>What are the consequences/benefits:<br>- Contributors will know what is allowed or not.<br>- It is possible to "guard" against using too new language features (esp. for C and C++) or using too old features (esp. Python). In this respect we're setting a max support for C/C++, and min support for Python.<br>- Existing C and C++ code compiles also with C17 and C++17, and will **not** have to be changed as a consequence of standard support policy.<br>- Old Python code may be discarded.<br><br><br>I think Anna's suggestion to look at how GDAL is handling the question on Python with a long term strategy is a good way to go, but we need to consider GRASS has a different release schedule.<br>(I personally believe 3.6 is too conservative for G8. When the moment comes for G8 release, I suspect 3.6 is close to if not past end-of-life.)<br><br><br>It would be most favourable for all contributors and the project if the community could come to an agreement on this topic. I see no reason to postpone a decision on this much longer.<br><br>The final word on this need to be that of the PSC's. Whether through simple vote or a RFC. However, a sounding of the opinion of the dev-community on this matter is of equal importance and can be of help for the PSC.<br><br><br>May I propose setting the programming language standard support for the GRASS GIS 8:<br><br>PROPOSAL:<br>=========<br><br>- Python 3.6<br><br>- C11 with core (mandatory) features<br>    (optional features may be used if availability is tested with macro,<br>     and if not supported, alternative fallback code must be provided [3])<br><br>- C++11<br><br><br>Best,<br>Nicklas<br><br><br><br>[1] That must have been a h*** of a job! Respect!<br>[2] 4 core and 3 add-on modules.<br>[3] See <https://en.wikipedia.org/wiki/C11_(C_standard_revision)><br>    for short summary of C11 and list of its optional features.<br><br><br><br>            </div>            <div class="yahoo_quoted" style="margin:10px 0px 0px 0.8ex;border-left:1px solid #ccc;padding-left:1ex;">                        <div style="font-family:'Helvetica Neue', Helvetica, Arial, sans-serif;font-size:13px;color:#26282a;">                                <div>                    On Tuesday, 9 February 2021, 22:29:49 CET, Markus Metz <markus.metz.giswork@gmail.com> wrote:                </div>                <div><br></div>                <div><br></div>                <div><div id="yiv8723910078"><div><div dir="ltr"><div>Just for clarification,</div><div><br clear="none"></div><div>C code written for an older C standard works fine with newer C standards.<br clear="none"><br clear="none">This is different with Python: code written for a previous Python version might no longer work with a newer Python version. </div><div><br clear="none"></div><div>Increasing the C standard for existing GRASS C code is safe, it will still compile and work.<br clear="none"></div><div><br clear="none"></div><div>Increasing the Python version is not safe because existing GRASS Python code might not be compatible with newer Python versions, thus the need for a minimum required Python version.</div><div><br clear="none"></div><div>Markus M<br clear="none"></div><div><div class="yiv8723910078yqt9797475105" id="yiv8723910078yqtfd11288"><br clear="none">On Sun, Feb 7, 2021 at 10:36 PM Markus Metz <<a rel="nofollow noopener noreferrer" shape="rect" ymailto="mailto:markus.metz.giswork@gmail.com" target="_blank" href="mailto:markus.metz.giswork@gmail.com">markus.metz.giswork@gmail.com</a>> wrote:<br clear="none">><br clear="none">><br clear="none">><br clear="none">> On Sun, Feb 7, 2021 at 4:07 PM Moritz Lennert <<a rel="nofollow noopener noreferrer" shape="rect" ymailto="mailto:mlennert@club.worldonline.be" target="_blank" href="mailto:mlennert@club.worldonline.be">mlennert@club.worldonline.be</a>> wrote:<br clear="none">> ><br clear="none">> ><br clear="none">> ><br clear="none">> > Am 7. Februar 2021 05:01:38 MEZ schrieb "Anna Petrášová" <<a rel="nofollow noopener noreferrer" shape="rect" ymailto="mailto:kratochanna@gmail.com" target="_blank" href="mailto:kratochanna@gmail.com">kratochanna@gmail.com</a>>:<br clear="none">> > >On Wed, Feb 3, 2021 at 2:47 PM Anna Petrášová <<a rel="nofollow noopener noreferrer" shape="rect" ymailto="mailto:kratochanna@gmail.com" target="_blank" href="mailto:kratochanna@gmail.com">kratochanna@gmail.com</a>> wrote:<br clear="none">> > ><br clear="none">> > >><br clear="none">> > >><br clear="none">> > >> On Tue, Feb 2, 2021 at 11:20 AM Nicklas Larsson <<a rel="nofollow noopener noreferrer" shape="rect" ymailto="mailto:n_larsson@yahoo.com" target="_blank" href="mailto:n_larsson@yahoo.com">n_larsson@yahoo.com</a>><br clear="none">> > >> wrote:<br clear="none">> > >><br clear="none">> > >>><br clear="none">> > >>><br clear="none">> > >>><br clear="none">> > >>><br clear="none">> > >>><br clear="none">> > >>> On Friday, 29 January 2021, 18:50:34 CET, Anna Petrášová <<br clear="none">> > >>> <a rel="nofollow noopener noreferrer" shape="rect" ymailto="mailto:kratochanna@gmail.com" target="_blank" href="mailto:kratochanna@gmail.com">kratochanna@gmail.com</a>> wrote:<br clear="none">> > >>><br clear="none">> > >>><br clear="none">> > >>><br clear="none">> > >>><br clear="none">> > >>><br clear="none">> > >>><br clear="none">> > >>><br clear="none">> > >>> On Thu, Jan 28, 2021 at 4:28 AM Nicklas Larsson via grass-dev <<br clear="none">> > >>> <a rel="nofollow noopener noreferrer" shape="rect" ymailto="mailto:grass-dev@lists.osgeo.org" target="_blank" href="mailto:grass-dev@lists.osgeo.org">grass-dev@lists.osgeo.org</a>> wrote:<br clear="none">> > >>> > Dear Devs!<br clear="none">> > >>> ><br clear="none">> > >>> > As a relatively new member of the GRASS GIS dev community, I have had<br clear="none">> > >>> to search for information on mailing lists, old trac comments etc.<br clear="none">> > >>> regarding coding practice and in particular minimum programming language<br clear="none">> > >>> standard support. Ending up in not entirely conclusive understanding. Up<br clear="none">> > >>> until now, I have been mostly involved in Python development and I’m still<br clear="none">> > >>> not absolutely certain, although I assume 3.5 is minimum version. And I’m<br clear="none">> > >>> not alone, see e.g. [1].<br clear="none">> > >>> ><br clear="none">> > >>> > Now, I’ve encountered a similar dilemma with C standard support,<br clear="none">> > >>> attempting to address compiler warnings [2], in particular with the PR<br clear="none">> > >>> #1256 [3].<br clear="none">> > >>> ><br clear="none">> > >>> > I would be great if there were a (one) place where the min support of<br clear="none">> > >>> Python version, C (C89, C99, C11, C17…) and C++ (C++03, C++11, C++14 …)<br clear="none">> > >>> standard is stated -- loud and clear. Obviously, there has to be a<br clear="none">> > >>> consensus in the community on these matters for that to happen. Such a<br clear="none">> > >>> statement will also have to be revised now and then. (A related question is<br clear="none">> > >>> also whether or not to support 32 bit, which I know have been raised<br clear="none">> > >>> recently).<br clear="none">> > >>> ><br clear="none">> > >>> > I’d appreciate your opinion is on this issue!<br clear="none">> > >>> > Let me put up a a suggestion for min. req. for coming GRASS GIS 8 as a<br clear="none">> > >>> starting point of discussion:<br clear="none">> > >>> > - Python 3.7<br clear="none">> > >>> > - C11<br clear="none">> > >>> > - C++11<br clear="none">> > >>> ><br clear="none">> > >>> ><br clear="none">> > >>> > Best regards,<br clear="none">> > >>> > Nicklas<br clear="none">> > >>> ><br clear="none">> > >>><br clear="none">> > >>> Regarding Python, not sure if we shouldn't set 3.6 as minimum for G8, it<br clear="none">> > >>> is still used e.g. in Ubuntu 18. Any reason to set 3.7 as minimum, some<br clear="none">> > >>> specific features we would want to use?<br clear="none">> > >>><br clear="none">> > >>> Anna<br clear="none">> > >>><br clear="none">> > >>> ><br clear="none">> > >>> ><br clear="none">> > >>> > [1] <a rel="nofollow noopener noreferrer" shape="rect" target="_blank" href="https://github.com/OSGeo/grass/issues/1241">https://github.com/OSGeo/grass/issues/1241</a><br clear="none">> > >>> > [2] <a rel="nofollow noopener noreferrer" shape="rect" target="_blank" href="https://github.com/OSGeo/grass/issues/1247">https://github.com/OSGeo/grass/issues/1247</a><br clear="none">> > >>> > [3] <a rel="nofollow noopener noreferrer" shape="rect" target="_blank" href="https://github.com/OSGeo/grass/pull/1256">https://github.com/OSGeo/grass/pull/1256</a><br clear="none">> > >>> ><br clear="none">> > >>> > _______________________________________________<br clear="none">> > >>> > grass-dev mailing list<br clear="none">> > >>> > <a rel="nofollow noopener noreferrer" shape="rect" ymailto="mailto:grass-dev@lists.osgeo.org" target="_blank" href="mailto:grass-dev@lists.osgeo.org">grass-dev@lists.osgeo.org</a><br clear="none">> > >>> > <a rel="nofollow noopener noreferrer" shape="rect" target="_blank" href="https://lists.osgeo.org/mailman/listinfo/grass-dev">https://lists.osgeo.org/mailman/listinfo/grass-dev</a><br clear="none">> > >>> ><br clear="none">> > >>> ><br clear="none">> > >>><br clear="none">> > >>><br clear="none">> > >>><br clear="none">> > >>> Well, I don’t have a very strong opinion regarding 3.7, but personally<br clear="none">> > >>> I’d say 3.6 is an absolute minimum. I presume, for example, most of us<br clear="none">> > >>> would prefer to use f-strings for string formatting.<br clear="none">> > >>><br clear="none">> > >><br clear="none">> > >> yes, f-strings are nice although they have limitations for using with<br clear="none">> > >> translatable strings (Vashek can expand on that)<br clear="none">> > >><br clear="none">> > >>><br clear="none">> > >>><br clear="none">> > >>> On the other hand, 3.6 will reach end-of-support at the end of this year<br clear="none">> > >>> right after its 5th birthday party and the support for data classes in 3.7<br clear="none">> > >>> may potentially offer intriguing applications in G8.<br clear="none">> > >>><br clear="none">> > >><br clear="none">> > >> I noticed the data classes as well. Given 3.6 is reaching end-of-support<br clear="none">> > >> soon, I agree with 3.7 for G8. I assume grass would be compatible with 3.6<br clear="none">> > >> for a while anyway.<br clear="none">> > >><br clear="none">> > >><br clear="none">> > >>> Ubuntu 18 has Python 3.6 and Debian 9 has Python 3.5! What will make the<br clear="none">> > >>> lowest common denominator? Debian 10 and Ubuntu 20 actually supports Python<br clear="none">> > >>> 3.7 and 3.8 respectively. Forgive me if I’m ignorant, but isn’t it possible<br clear="none">> > >>> to upgrade Python version on Ubuntu? Or is it just a pain with package<br clear="none">> > >>> dependencies? Relying on default Python has never/rarely been a luxury for<br clear="none">> > >>> other platforms.<br clear="none">> > >>><br clear="none">> > >>> That being said, I think the most important part of this is that the<br clear="none">> > >>> community make a clear decision on min. supported Python version.<br clear="none">> > >>><br clear="none">> > >><br clear="none">> > >This GDAL's RFC [1] is helpful in summarizing the issue with Python.<br clear="none">> > >Looking more into this, I suggest to go have a longer term strategy for<br clear="none">> > >dropping support for Python versions, which would be relatively simple.<br clear="none">> > >Basically we would keep the lowest Python version that wouldn't reach end<br clear="none">> > >of life at the time of a major release of GRASS. E.g. when we release G8<br clear="none">> > >this year, 3.6 will be minimum maintained version. Since 3.6 ends Dec 2021,<br clear="none">> > >we could drop 3.6 support next year. I am not saying we need to be strict<br clear="none">> > >about that, but might be helpful as a guidance, and it is independent on<br clear="none">> > >distributions (which is probably both advantage and disadvantage). I am<br clear="none">> > >unsure how this decision impacts packaging of grass, i.e. once we set 3.7<br clear="none">> > >as minimum, would maintainers need to make that Python a dependency of<br clear="none">> > >GRASS? Anyway, to summarize, I am for Python 3.6 at this point, but we need<br clear="none">> > >to reevaluate that with each new major GRASS version. I think this is<br clear="none">> > >conservative enough and perhaps more in line with the C standards<br clear="none">> > >discussion.<br clear="none">> > ><br clear="none">> ><br clear="none">> > +1<br clear="none">> ><br clear="none">> > Moritz<br clear="none">><br clear="none">> +1<br clear="none">><br clear="none">> Markus M<br clear="none">><br clear="none"></div></div></div><div class="yiv8723910078yqt9797475105" id="yiv8723910078yqtfd78754"></div></div></div></div>            </div>                </div>