Drop support EOL Pythons

[jdufresne]

Python 2.7 and 3.4, and 3.5 are end of life. They are no longer
receiving bug fixes, including for security issues.

For a list of supported and EOL Pythons, see:

Supported: https://devguide.python.org/#status-of-python-branches
EOL: https://devguide.python.org/devcycle/#end-of-life-branches

Removing support for EOL Pythons will reduce testing and maintenance
resources while allowing the library to move towards a modern Python 3
style.

Next steps

• Do one additional release that supports Python 2.7 to include recent changes
• Create a "1.x" or "python2.7-support" branch to allow ongoing Python 2 maintenance
• Bump the major version number on the master branch (not necessary)
• Review and merge PR Drop support for EOL Pythons #281
• Do another release for Python 3+

[hartwork]

Regrading the major version bump: Personally I don't think a bump in major version is needed or even helpful because it signals breaking changes (a la semver) to the users of alive Python versions (who don't need any signal) while it doesn't signal anything to user of end-of-life versions of Python (due to proper python_requires). I get the idea but I think the details work against the intent. What do you think?

[jdufresne]

@hartwork That is fine by me. Reading through the Semantic Versioning spec suggests that you're right. There is no change to the API, so no need for a version bump. I'll strike that step.

https://semver.org/#what-should-i-do-if-i-update-my-own-dependencies-without-changing-the-public-api

[hartwork]

@jdufresne great, thank you! 🙏

[brejoc]

Hm… I don't know, I have kind of a mixed feeling about the version bump here. While it might not be strictly necessary according to semver, dropping Python2 is a big change and people might associate the expectation of a major version bump with that.

[hartwork]

@brejoc what you describe is inherent to doing semantic versioning: You bump major versions on contract breaking changes, no matter how small or big.

[funkyfuture]

given the axioms that SemVer doesn't require the major bump, while many projects did that to reflect the drop of Python 2 and a bump to a 1.0 release signals a complete and stable interface, another question that may be asked is: is the interface close enough to completeness and stability so that we aim to address the missing parts for it and then make the major bump w/o any preceding releases?

[sethmlarson]

Alright I think it's decided then. Once we merge the PR removing Python 2.7 support I'll create a branch off of whatever the last commit was called python2.7-support. I'm guessing similarly to the python2.6-support branch it'll be supported only if the community opens PRs there.

Before this we'll have to create one last release though.

[jdufresne]

Before this we'll have to create one last release though.

I think we're in a good position do this. @sethmlarson would you like to go ahead?

[sethmlarson]

Created a changelog here: #301

[sethmlarson]

Created the branch python2.7-support which is everything up to the commit dropping Python 2.7.

[sethmlarson]

I think we can mark this as completed. The next release will complete this issue so going to close now as there's nothing in particular anyone has to do. Thanks everyone!