Python3 Strategy #47
Description
I am working on a port of pyretic to python3 for my own needs. Things are looking good so far, I am just wondering what your approach to supporting py2 and py3 is.
I guess there's not much demand yet from pyretic users for py3 compatibility, so having py2 support may be a desired feature. It would probably be too much maintenance effort to develop simultaneously on py2 and py3 branches. I would suggest there are a two options to maintaining py2 and py3:
- One codebase which is py2 and py3 compatible (using something like six)
- Move forwards with master py3-only, tag current release as py2 and move forward with py3, backporting important changes if necessary.
The porting that I have done for myself does not support py2 and py3 compatibility, but it would probably be possible to make it work. Py3 is not going anywhere and py2 will not progress past 2.7.x, so developing for py3 on master sort of matches current python development.
My question is: is there any reason why moving forward with the master branch being py3 and having a py2 tag for "backwards compatibility" is a terrible idea? If so, it might be worth investing the effort in having a single py2 and py3 compatible codebase, otherwise I would prepare a pull request with the python3 changes.