In the plan i outlined, the first python 3 only release would be the one that drops 3.4 mid-2019 - at that point in time the maintenance branch would be prepared before release merge time.
I see, thanks, forgot that 3.4 EOL is mid 2019.
Once we make a release dropping Python 2 and the maintenance branch is up, what will be our policy regarding large changes in the codebase? I mean, once we have access to Python3 only features, I suspect we will want to clean up the codebase quite a bit and make use of those features (keyword-only arguments come to mind). This clean up and use of new features will make porting critical bug-fixes to the maintenance branch a lot more difficult. Should we hold on on large changes Python 3 only changes until Python 2 EOL, or just bite the bullet and see what happens when we try to port critical fixes to the maintenance branch?
Also this reminds me: we should document clearly what we consider "critical" that should be ported to the maintenance branch.
Cheers,.
Meaning that instead of actively working on porting changes and pushing
releases,
we instead support the wider community with needs to bring in changes
they require and support them with review and releasing.
I believe half a year is more than enough to stabilize and sort out the
2.7 maintenance branch,
but should i be demonstrated wrong by how this unfolds i'm happy to have
this extend this for another year.
But for anything after that the bulk of the python2.x maintenance work
should be left on the shoulders of companies and individuals that have
an actual requirement for that.
-- Ronny
_______________________________________________
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev