Run tests with all supported versions (drop Python 3.3 support)

[chrysn]

If it isn't tested, it doesn't work. Worse enough the code coverage is not near 100% yet, but Python 3.4 continuously breaks due to old syntax glitches, careless use of 3.5 idioms and what so not.

Mitigation:

• Run CI on all supported versions
• Drop Python 3.3 support because while the Gitlab CI runners do support it, I can't eaily reproduce failures in development because no stable Debian release shipped that version.

(Those applications I had in mind that justified Python 3.3 support, PyPy and micropython, would need dedicated tests anyway. If you want to run aiocoap on a particular Python 3.3 setup, open an issue and we'll figure something out.)

[aellwein]

If it isn't tested, it doesn't work. Worse enough the code coverage is not near 100% yet, but Python 3.4 continuously breaks due to old syntax glitches, careless use of 3.5 idioms and what so not.

A stupid question: why not go further and only support the latest Python versions, e.g. 3.6+ ? Are there outside some devices which depend on the 3.3-3.4 ? The latest two Python releases contain major improvements to asyncio and overall. I think this project can only profit from it, if there are no reasons to stick with the compatibility.

[chrysn]

(Stupid question? Not at all!)

I do use aiocoap on our production servers that run Debian Jessie (and thus Python 3.4.2). The main cost of supporting Python 3.4/3.5 right now is not using modern async def idiom in the core parts (a minor annoyance), and sporadic bugs that only got caught late so far because the test suite didn't cover 3.4 (eg. whatever syntax oddity there was that made 1993947 necessary, async details I missed like d3669b7 or f5b58d2).

My rough roadmap w/rt old versions right now is to support whatever Python version is in the latest Debian release. (Fedora and Ubuntu with their shorter release cycles should be covered by this too). Feedback like yours helps in that decision; thanks.