I personally don't want to do this for 3.0. There is no pressing need right now AFAICT, and keeping a slightly bigger overlap in the compatibility with 2.5 is a good thing.

@filmor it would still work, but won't be officially supported. Our CI runs would be slightly less wasteful.

If you look at NumPy, their drop support policy for new releases is much more aggressive. In fact, they already dropped support for 3.7 in new releases.

@mjmvisser what are Unity plans in regards to supported Python versions?

@filmor reconsider before 3.0? What's the overlap for? Unity was already on 3.7 at the time I sent this PR.

Most of the new packages releases on PyPi do not support 3.6 anymore. If people need legacy code, they can continue using 2.5.2.

I still don't see the point. It costs us nothing to keep the support around until we require a >= 3.7 feature.

@filmor and once we do, it would require a major version bump to drop support for 3.6 if we follow semver

What, why? I have never seen that logic practiced anywhere, see also https://semver.org/#what-should-i-do-if-i-update-my-own-dependencies-without-changing-the-public-api.

@filmor this might be OK on PyPi, but on NuGet pythonnet does not explicitly depend on Python, and I would consider supported Python version to be a part of public API.

Anyway, I am fine with keeping it. I just don't like the approach, when stuff is kept around without explicit justification. It is always "easy" to "just keep it around", but it is not a good justification on its own. Neither of the 3 active participants in pythonnet use 3.6 anymore.

Being stuck with old setuptools convinces me :)