Travis builds fail due to missing python2.6 and python3.3

[sirosen]

@jpadilla, this is probably your call in terms of what lengths you want to go to in order to support these platforms, since it doesn't look like Travis py3.6 workers have these pythons anymore.

This happened in builds for #296, and it will impact other changes too.

Drop 2.6?

If there's no testing on py2.6, pyjwt should drop the classifier for it: otherwise something like "{}".format("foo") will slip in, and on 2.6 it will break.
2.6 is really old at this point. Is support for it important?

The last non-secuirty-fix release of 2.6 was almost a decade ago.

Drop 3.3?

Python3 moves fast, and 3.3 is one of the older versions at this point.
It was released in 2012 and has been in security-fix-only maintenance since 2014 (py3.3.7 release notes).

Unlike the issues with 2.6, if it works on 2.7 and 3.4, it probably works on 3.3.
Still, IMO pyjwt should drop the classifier if it's not being tested.

Work hard to test 2.6 and/or 3.3?

The other option seems to be to have Travis explicitly install these pythons for tests to run.
For the reasons noted above, I don't think this is worth the work involved.

If you wanted to do it, one of the better routes is probably to refactor the way tests are run to leverage Travis' python version selection, rather than trying to run everything through tox.

[jpadilla]

I'm +1 on dropping 2.6 and 3.3 at this point.

[vimalloc]

I had CI break out from under me as well. It looks like the underlying cryptography library dropped support for python 3.3 with the 2.0 release: (https://github.com/pyca/cryptography/blob/master/CHANGELOG.rst#20---2017-07-17)

It is also dropping support for python 2.6 in the forthcoming 2.2 release:(https://github.com/pyca/cryptography/blob/master/CHANGELOG.rst#22---master).

Seems like dropping support for 2.6 and 3.3 here would be a good idea.

[jpadilla]

Closed via #301