We've decided that python-3.5 is the minimum python version (#17270)

.travis.yml

@@ -15,8 +15,6 @@ matrix:
       python: 2.6
     - env: TARGET=sanity TOXENV=py27
       python: 2.7
-    - env: TARGET=sanity TOXENV=py34
-      python: 3.4
     - env: TARGET=sanity TOXENV=py35
       python: 3.5
     - env: TARGET=sanity TOXENV=py24

Makefile

@@ -93,7 +93,7 @@ MOCK_CFG ?=
 
 NOSETESTS ?= nosetests
 
-NOSETESTS3 ?= nosetests-3.4
+NOSETESTS3 ?= nosetests-3.5
 
 ########################################################
 

docsite/rst/developing_modules_python3.rst

@@ -13,42 +13,41 @@ factors that make it harder to port them than most code:
 Which version of Python-3.x and which version of Python-2.x are our minimums?
 =============================================================================
 
-The short answer is Python-3.4 and Python-2.4 but please read on for more
+The short answer is Python-3.5 and Python-2.4 but please read on for more
 information.
 
-For Python-3 we are currently using Python-3.4 as a minimum.  However, no long
-term supported Linux distributions currently ship with Python-3.  When that
-occurs, we will probably take that as our minimum Python-3 version rather than
-Python-3.4.  Thus far, Python-3 has been adding small changes that make it
-more compatible with Python-2 in its newer versions (For instance, Python-3.5
-added the ability to use percent-formatted byte strings.) so it should be more
-pleasant to use a newer version of Python-3 if it's available.  At some point
-this will change but we'll just have to cross that bridge when we get to it.
+For Python-3 we are currently using Python-3.5 as a minimum on both the
+controller and the managed nodes.  This was chosen as it's the version of
+Python3 in Ubuntu-16.04, the first long-term support (LTS) distribution to
+ship with Python3 and not Python2.  Much of our code would still work with
+Python-3.4 but there are always bugfixes and new features in any new upstream
+release.  Taking advantage of this relatively new version allows us not to
+worry about workarounds for problems and missing features in that older
+version.
 
-For Python-2 the default is for modules to run on Python-2.4.  This allows
-users with older distributions that are stuck on Python-2.4 to manage their
-machines.  Modules are allowed to drop support for Python-2.4 when one of
-their dependent libraries require a higher version of python.  This is not an
-invitation to add unnecessary dependent libraries in order to force your
-module to be usable only with a newer version of Python.  Instead it is an
-acknowledgment that some libraries (for instance, boto3 and docker-py) will
-only function with newer Python.
+For Python-2, the default is for the controller to run on Python-2.6 and
+modules to run on Python-2.4.  This allows users with older distributions that
+are stuck on Python-2.4 to manage their machines.  Modules are allowed to drop
+support for Python-2.4 when one of their dependent libraries require a higher
+version of python.  This is not an invitation to add unnecessary dependent
+libraries in order to force your module to be usable only with a newer version
+of Python.  Instead it is an acknowledgment that some libraries (for instance,
+boto3 and docker-py) will only function with newer Python.
 
 .. note:: When will we drop support for Python-2.4?
 
     The only long term supported distro that we know of with Python-2.4 is
     RHEL5 (and its rebuilds like CentOS5) which is supported until April of
-    2017.  We will likely end our support for Python-2.4 in modules in an
-    Ansible release around that time.  We know of no long term supported
-    distributions with Python-2.5 so the new minimum Python-2 version will
-    likely be Python-2.6.  This will let us take advantage of the
-    forwards-compat features of Python-2.6 so porting and maintainance of
-    Python-2/Python-3 code will be easier after that.
+    2017.  Whatever major release we make in or after April of 2017 (probably
+    2.4.0) will no longer have support for Python-2.4 on the managed machines.
+    Previous major release series's that we support (2.3.x)  will continue to
+    support Python-2.4 on the managed nodes.
 
-.. note:: Ubuntu 16 LTS ships with Python 3.5
+    We know of no long term supported distributions with Python-2.5 so the new
+    minimum Python-2 version will be Python-2.6.  This will let us take
+    advantage of the forwards-compat features of Python-2.6 so porting and
+    maintainance of Python-2/Python-3 code will be easier after that.
 
-    We have ongoing discussions now about taking Python3-3.5 as our minimum
-    Python3 version.
 
 Supporting only Python-2 or only Python-3
 =========================================
@@ -152,7 +151,7 @@ dealing with file permissions.  (With file permissions a user may be feeding
 the mode into another program or to another module which doesn't understand
 the python syntax for octal numbers.  ``[zero][digit][digit][digit]`` is
 understood by most everything and therefore the right way to express octals in
-these cisrcumstances.
+these circumstances.
 
 Bundled six
 -----------

shippable.yml

@@ -51,8 +51,6 @@ matrix:
       python: 2.6
     - env: TEST=sanity INSTALL_DEPS=1 TOXENV=py27
       python: 2.7
-    - env: TEST=sanity INSTALL_DEPS=1 TOXENV=py34
-      python: 3.4
     - env: TEST=sanity INSTALL_DEPS=1 TOXENV=py35
       python: 3.5
 

tox.ini

@@ -1,8 +1,5 @@
 [tox]
-envlist = py26,py27,py34,py35
-
-[testenv:py34]
-deps = -r{toxinidir}/test/utils/tox/requirements-py3.txt
+envlist = py26,py27,py35
 
 [testenv:py35]
 deps = -r{toxinidir}/test/utils/tox/requirements-py3.txt
@@ -14,7 +11,6 @@ commands =
     python --version
     py26: python -m compileall -fq -x 'test/samples|contrib/inventory/vagrant.py' lib test contrib
     py27: python -m compileall -fq -x 'test/samples' lib test contrib
-    py34: python -m compileall -fq -x 'test/samples|lib/ansible/modules' lib test contrib
     py35: python -m compileall -fq -x 'test/samples|lib/ansible/modules' lib test contrib
     make tests