Python 3 minimum version bump before parity? Documenting when we raise versions

[atcuno]

@ikelos David and I were looking at some Python versions we have on dev machines and wanted to know if we should bump the minimum version before parity.

Looking at the chart:

https://devguide.python.org/versions/

3.8, our current minimum, was EOL on 2024-10-07. The cadence appears to be deprecating one minor version per year.

If we don't bump from 3.8 then we at least wanted an answer here that we could link people to when they ask how we will deal with version bumps going forward - plus for our own knowledge.

[ikelos]

In general the guidance has been to support older versions until there's a compelling reason not to. I think 3.10 has easier-to-read typing information (Thing | None rather than Optional[Thing]) which I'd quite like but otherwise there's no features we need/want that mean we need to break 3.8 (I think we only went to 3.8 because of the pip/yara stuff). But yeah, basically, as old as we can manage unless we need features that that old doesn't support. We should ensure we cover at least all in-life versions of python (so no one can have a supported python that volatility doesn't work on).

We can bump if we want to get rid of older versions, but without a need I'd ask why we'd bother?