Defining a Python release support policy

[mpounsett]

I'm considering what the project policy should be around Python version support. I'm going to share my ideas about this, but I'm interested in getting some community feedback before I take action.

The main issue that I want to address is that there are language features that I would like to be able to take advantage of, but can't, because they are not available in older versions of Python. There is a secondary issue of needing to run tests on all the supported Python versions. That not only takes time, but also requires anyone making contributions to have many Python versions installed in their environment. Due to dependency requirements, I can no longer install Python 3.4 on my Mac laptops, which means I need to run those tests on another platform, which is irritating and messes with my "test before committing" workflow.

I'm considering the blanket policy that this project supports any Python release which is currently supported by the Python project. This would be any release in the Active Python Releases table which has not reached its End Of Support date. I see two potential problems with this blanket policy:

1. The policy would immedaitely result in dropping Python 2.7 support, but I don't know what the Python 2.7 use of nagiosplugin is still like. Are people still deploying it in Python 2.x environments?

   If they are, then I need to consider what's involved in dropping Python 2.x support. This might mean waiting for nagiosplugin 2.0, since dropping a supported language version could be argued to be an API-breaking change, depending on how you read the rules of semantic versioning.

2. I know some OS releases don't keep up with language releases very well.

   I can't think of current examples, but I know there have been times in the fairly recent past where I was supporting Linux server deployments running distributions with out of support releases of Python as the system Python release. If this problem is still cropping up in any of the Unixes or in Windows then of course a policy such as the above would be problematic.

If I need to support Python releases beyond their End of Support, I would need some other objective measure by which to decide when a release can be dropped. I don't know what that would be, so if anyone thinks the suggested policy is a bad idea, I would like to hear from you about what other measurable thing I could use to decide how long a Python release needs to be supported.

Thanks for your time reading this, and thanks in advance for any comments or input.

[sbraz]

Here's what I think:

• On one hand, people who run nagios plugins might do so on old systems
• On the other hand, they might not need the latest nagiosplugin versions
• All supported Linux distributions support Python 3 so in my (subjective) opinion, you could drop Python 2
• You could check what old supported Linux distros offer:
  • Debian stretch (EoL in a June 2022) has Python 3.5
  • Ubuntu Bionic (EoL in 2023) has Python 3.6
  • CentOS 7 supports Python 3.6 via software collections

If it were up to me, I would probably support only Python 3.5 and newer, maybe even 3.6.

[mpounsett]

On one hand, people who run nagios plugins might do so on old systems
On the other hand, they might not need the latest nagiosplugin versions

This is part of my line of reasoning too.

The trouble I have with trying to support any Python release which is current in any currently supported Linux distribution is that that many distributions routinely run really old software. Supporting Python 3.7 or newer (currently supported Python releases) means I'm restricted to language and standard library features that are four years old or more. If I support Python 3.5 or later, that extends out to at least seven years. That significantly restricts what I can do with the code.

But, as we were both saying, people running old code on their systems don't necessarily need the latest bleeding edge version of nagiosplugin.

I'll wait another couple of weeks to see if there's any other response, and then make a decision.

[sbraz]

What new features do you use out of curiosity? Except a few things that were added to pathlib recently and f-strings, I don't think I use so many "modern" features (post-3.6) but maybe I just don't write enough code 😛

[mpounsett]

While function parameter type hints showed up in 3.5, type hints for variables weren't introduced until 3.6. In addition to being a useful helper in IDE environments, and just being good style, type hinting would fix specific linting errors, such as the inconsistent return statements error generated by the exit call in the Runtime object's non-returning error handler.

3.6 introduced formatted strings, os.PathLike, local time disambiguation for DST, and UTF-8 encoding for Windows paths.

Dataclasses were introduced in 3.7, and I think they might be useful reimplementing some of nagiosplugin's core classes (#45) (maybe.. I have to take a closer look, but there's no point if I'm trying to support 3.5). 3.7 also introduced new time functions with nanosecond resolution, and more comprehensive options for deprecation exceptions, which are of interest in a project with public APIs.

There are also features of 3.8, 3.9, and 3.10 that would be nice to have access to sooner, rather than later... like the := operator, Union types, and structural pattern matching.