Skip to content

Drop support for EOL Python 2.6 and 3.2#314

Merged
benjaminp merged 3 commits into
benjaminp:masterfrom
hugovk:rm-2.6-3.2
Jan 8, 2020
Merged

Drop support for EOL Python 2.6 and 3.2#314
benjaminp merged 3 commits into
benjaminp:masterfrom
hugovk:rm-2.6-3.2

Conversation

@hugovk

@hugovk hugovk commented Dec 14, 2019

Copy link
Copy Markdown
Contributor

Fixes #308.

Stops testing them on the CI, update python_requries and remove some code specifically for those versions.

Not done anything to remove any six functionality that's only a benefit on those versions, that should be in a separate PR and would be a breaking change that should ideally deprecate first.

@benjaminp benjaminp merged commit ac4bdc5 into benjaminp:master Jan 8, 2020
@hugovk hugovk deleted the rm-2.6-3.2 branch January 8, 2020 05:02
@relrod

relrod commented Jul 1, 2020

Copy link
Copy Markdown

@benjaminp We bundle six in Ansible because we need to ship it over the wire to remote hosts to run modules before we know which version of Python they are using. In Ansible, we support Python 2.6 on remote hosts, so we depend on 2.6 support in six. We also have users who use newer Python, so going forward not updating six won't be an option for us. So with this change we're stuck between a rock and a hard place.

I'm not sure what the argument for dropping 2.6 support was (since 2.7 is EOL too but that still seems supported), but is there any way you would you reconsider this decision and bring it back?

@benjaminp

Copy link
Copy Markdown
Owner

As the linked issue describes, as software becomes increasingly obsolete, it becomes increasingly odious to maintain the CI environments that ensures that it works.

six must be one of the last projects in the world to drop 2.6 support. Core infrastructure like pip has not supported 2.6 for years.

@relrod

relrod commented Jul 2, 2020

Copy link
Copy Markdown

@benjaminp Yeah, completely understood. Unfortunately we're stuck supporting it for a while longer and there's not much we can do about that, so this puts us in a bit of a pickle outside of having to maintain our own bundled fork and backporting features. I was just hoping you might reconsider if we raised the flag on it, since this is a py2/py3 compat library. I do understand the concerns though.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

drop support for Python 2.6 and 3.2

3 participants