Drop support for Python 3.6

[bluetech]

Python 3.6 reached end-of-life at 2021-12-23. In the past, we dropped support for end-of-life Python versions in feature releases. So we should drop support for Python 3.6 in the pytest 7.1 release (current main branch).

For reference, the issue where we dropped 3.5: #7808

[nicoddemus]

👍

We don't have a policy in place for when a Python version should be dropped, but:

After a Python version reaches EOL, the next minor pytest release will no longer support that Python version.

Seems reasonable to me. If everybody agrees, we should add these to the docs in backwards-compatibility.rst (I volunteer to do it).

[bluetech]

👍 from me

[nicoddemus]

So we should drop support for Python 3.6 in the pytest 7.1 release (current main branch).

Btw, just occurred to me, but in that scenario, what are the implications that Python 3.6 users will be able to use pytest 7.0 (where deprecations turned into errors) but not pytest 7.1 (where the deprecated features have been removed)? Seems a bit strange in that regard, because major releases are special in that way (turning warnings into errors).

Having said that, wouldn't make more sense to allow dropping Python versions even in major releases? I think it is cleaner to have pytest 7.0 and onward to support only Python 3.7+.

I'm curious if there's a rationale for "only drop support in minor versions", or if (by chance) this is just how that was done in the past?

Nevermind, just remembered that we actually dropped Python 2 support in pytest 5.0, so there's precedence for dropping Python version support in a major release.

So I think #9442 should be backported to 7.0.x and released in 7.0.0.

[bluetech]

FWIW, I interpreted "the next minor pytest release" to also include major releases, that is I agree.

Regarding backport to 7.0.x, I defer to the release manager @The-Compiler.

[The-Compiler]

Personally I'd prefer to do this in 7.1, but I'll have to admit that my own project (qutebrowser) is part of the reason why. Here are my thoughts:

• Projects might not be able (or want) to drop 3.6 right away (for qutebrowser, I'm going to do that in its 3.0.0 release, but that's still some 2 months or so away, because there are some other big changes for it). Note I'm mainly thinking about applications here, rather than libraries (where pip will take care of picking the right version).
• The gap between 6.3.x and 7.0.0 is unusually large (more than a year).
• Due to some backwards-incompatible changes (and that large gap), it would likely be easier for projects if they could upgrade to pytest 7 without having to care about keeping pytest 6 compatibility around.

On the other hand, it might make our life harder if we need to keep compatibility around until 7.1.0 is out, but I suppose that won't be for long. WDYT?

[nicoddemus]

The gap between 6.3.x and 7.0.0 is unusually large (more than a year).

Good point, I think this is a strong argument to NOT drop support for Python 3.6 in 7.0. 👍

However it might make more sense to drop Python 3.6 in 7.2 instead, if possible: as I said a major release and the next minor release are "close"/"tied" together, and are usually released close to one another anyway.

So I propose we wait to drop Python 3.6 in 7.2 instead, if possible, but I'm splitting hairs here too, so if we want to go with dropping 3.6 in 7.1 I don't think it will be the end of the world. 😁

[bluetech]

what are the implications that Python 3.6 users will be able to use pytest 7.0 (where deprecations turned into errors) but not pytest 7.1 (where the deprecated features have been removed)? Seems a bit strange in that regard, because major releases are special in that way (turning warnings into errors).

To me this seems fine, mostly orthogonal to the issue - can you explain a bit more what problems/confusion you think this situation might cause?

[nicoddemus]

Actually nevermind, let's go with the simpler path of just dropping Python 3.6 in 7.1; reviewing the changelog of past releases I see the interval between X.0 and X.1 is longer than I recalled anyway.

[bluetech]

Fixed by #9442.