Python Support Policy

[mwaxmonsky]

It's amazing how quickly 5 years passes but Python 3.8 which was first released on 2019-10-14 was officially end of life'd on 2024-10-07 and is not longer receiving even security updates going forward.

Given that we no longer are going to get the same support policy that we enjoyed in the Python 2.7 days, it looks like we have 5 years from the initial release date of a given Python 3.x release until that release is end of life'd and the Python community has been demonstrably strict on this over the past 10 years according to the documentation (https://devguide.python.org/versions/#python-release-cycle)

I was wondering if we could get a pulse on what the current requirements are for needed versions of Python and if we can get a plan in place to have an official support policy/upgrade path for deprecating support for old and supporting newer versions of Python?

There are a ton of edge cases and things to take into consideration, understandably, on this front (and python is only the one I listed but this probably holds for any dependency) so I don't want to set up a policy that creates burdensome mandates but this is a catch-22 scenario as the longer we support out dated versions of Python, that means more edge cases/support needed to appease all interested parties and we may be losing out on leveraging newer features.

My initial thoughts are we could support the core versions of python on the main/develop branches and if any single entity needs an older version of Python supported, a branch can be created and it is that party's responsibility to maintain it and back port features/bug fixes.

Conversely, if the majority of interested parties need older versions of Python supported, we can leave everything as is until that need becomes more targeted and then follow the step above.

As for new versions, we could set up builds that are allowed to fail for future/latest and greatest releases and discuss what would need to change to support that version and determine if we should hold off or take on those changes into main/develop as the need/desire arises.

Thoughts? Ideas? Opinions?

I understand this will create more work for everyone so I am not pushing for anything immediately but think we should start having these conversations and getting a pulse on what our documented needs are and moving forward from there.

[climbfuji]

The Python versions to support is to a large extent determined by the software environments that the different users of CCPP employ. For UFS, SCM, and NEPTUNE, we use spack-stack on the HPCs. For UFS and NEPTUNE, we also use spack-stack as the supported solution for users on their own systems. I am not sure about what SCM does w.r.t. community support.

With spack-stack, we recently moved from 3.10.7 to 3.11.7. There may be a need to support 3.10.7 for a little longer, but we don't need to support 3.8 or 3.9 as far as UFS and NEPTUNE are concerned. But since 3.9 is still a supported version that is also commonly found in user environments, I would suggest keeping support for it. 3.12 doesn't work for spack-stack yet, but if the framework works with it then it would be good to be ahead of the curve.