Hi all, I had a read through this thread in the archives. It occurred before I joined the mailing list, so I hope that this email connects up with the thread properly for everyone.
I'd like to respond to the following points: I believe we are referring to two separate things with support: > - Supporting existing releases for patches - I agree that we need to give > users a long enough window to upgrade. Great if it happens with an LTS > release. Even if it does not, I think it will be fair to offer patches on > the last python 2 supporting release during some part of 2020 if that > becomes necessary. > - Making new releases with python 2 support - Each new Beam release with > python 2 support will implicitly extend the lifetime of beam's python 2 > support. I do not think we need to extend this to beyond 2019. 2 releases > (~ 3 months) after solid python 3 support will very likely put the last > python 2 supporting release to last quarter of 2019 already. With so many important features still under active development (portability, expansion, external IO transforms, schema coders) and new versions of executors tied to the Beam source, staying behind is not really an option for many of us, and with python3 support not yet fully completed, the window in which Beam is fully working for both python versions is rapidly approaching 2 months, and could ultimately be even less, depending on how long it takes to complete the dozen remaining issues in Jira, and whatever pops up thereafter. The cost of maintaining Python 2.7 support is higher than 0. Some issues > that come to mind: > - Maintaining Py2.7 / Py 3+ compatibility of Beam codebase makes it > difficult to use Python 3 syntax in Beam which may be necessary to support > and test syntactic constructs introduced in Python 3. > - Running additional test suites increases the load on test infrastructure > and increases flakiness. I would argue that the cost of maintaining a python2-only LTS version will be far greater than maintaining python2 support for a little while longer. Dropping support for python2 could mean a number of things from simply disabling the python2 tests, to removing 2-to-3 idioms in favor of python3-only constructs. If what you have in mind is anything like the latter then the master branch will become quite divergent from the LTS release, and backporting changes will be not be as simple as cherry-picking commits. All-in-all, I think it's a lose/lose for everyone -- users and developers, of which I am both -- to drop python2 support on such a short timeline. I'm an active contributor to this project and it will put me and the company that I work for in a very bad position if you force us onto an LTS release in early 2020. I understand the appeal of moving to python3-only code and I want to get there too, but I would hope that you give your users are much time to transition their own code as the Beam project itself has taken. I'm not asking for a full 12 months to transition, but more than a couple will be required. thanks, -chad
