Hi, I added a new BaseEventLoop.is_closed() method to Tulip and Python 3.5 to fix an issue (see Tulip issue 169 for the detail). The problem is that I don't want to add this method to Python 3.4 because usually we don't add new methods in minor versions of Python (future version 3.4.2 in this case). Guido just wrote in the issue: "Actually for asyncio we have special dispensation to push new features to minor releases (until 3.5). Please push to 3.4 so the source code is the same everywhere (except selectors.py, which is not covered by the exception)." I disagree with Guido. I would prefer to start to maintain a different branch for Python 3.4, because I consider that only bugfixes should be applied to Python 3.4. It's not the first change that cannot be applied on Python 3.4 (only in Tulip and Python 3.5): the selectors module now also supports devpoll on Solaris. It's annoying because the Tulip script "update_stdlib.sh" used to synchronize Tulip and Python wants to replace Lib/selectors.py in Python 3.4. I have to revert the change each time. I propose a new workflow: use Python default (future version 3.5) as the new asyncio "upstream". Bugfixes would be applied as other Python bugfixes: first in Python 3.4, than in Python 3.5. The "update_stdlib.sh" script of Tulip should be modified to copy files from Python default to Tulip (opposite of the current direction). Workflow: New feature: Python 3.5 => Tulip => Trollius Bugfix: Python 3.4 => Python 3.5 => Tulip => Trollius I don't think that Tulip should have minor release just for bugfixes, it would be a pain to maintain. Tulip is a third party module, it doesn't have the same constraints than Python stdlib. What do you think? Victor