Results of the "drop python 3" poll and what i envision to do about it
Hi Everyone, the python3 support poll has run its on https://twitter.com/ossronny/status/1043837215175057408 The results have a interesting shape. 37% now 09% with 3.4 mid 2019 38% with the python 2.7 eol 16% a year after py 2.7 eol 468 votes in the final result. Its my belief that a increase of the of the sample size wouldn't have changed the outcome of the poll. I observed it rather quickly normalizing into that shape. I consider the 2 peaks important indications of the desires and considerations of people. By my own wishes i'd just go ahead and drop python2 as well, but i don't consider 37% of the community sample to be enough to warrant something with such drastic effects right now. When summing up with the ~9% of the "with 3.4" and also weighting in the larger time-frame and my impression about the rounding twitter uses we get a subjective number of ~49%+-1%. Which i consider a good context for dropping the "general support for python3". So together with support for python3.4 i want pytest to drop support for python2 for the general development. As for maintenance branches for python2 - i proposed the setup in an earlier mail and i would like to make a basic outline for its support. the pytest core developers should actively support, maintain and backport to this branch until python2.7 goes eol, at that point we should transition the python2 maintenance involvement from the core developers from active to passive. 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
Hi Ronny, On Mon, Oct 1, 2018 at 5:01 AM RonnyPfannschmidt < opensource@ronnypfannschmidt.de> wrote:
Hi Everyone,
the python3 support poll has run its on https://twitter.com/ossronny/status/1043837215175057408
The results have a interesting shape.
37% now 09% with 3.4 mid 2019 38% with the python 2.7 eol 16% a year after py 2.7 eol
468 votes in the final result.
Its my belief that a increase of the of the sample size wouldn't have changed the outcome of the poll. I observed it rather quickly normalizing into that shape. I consider the 2 peaks important indications of the desires and considerations of people.
By my own wishes i'd just go ahead and drop python2 as well, but i don't consider 37% of the community sample to be enough to warrant something with such drastic effects right now. When summing up with the ~9% of the "with 3.4" and also weighting in the larger time-frame and my impression about the rounding twitter uses we get a subjective number of ~49%+-1%. Which i consider a good context for dropping the "general support for python3".
So together with support for python3.4 i want pytest to drop support for python2 for the general development.
As for maintenance branches for python2 - i proposed the setup in an earlier mail and i would like to make a basic outline for its support. the pytest core developers should actively support, maintain and backport to this branch until python2.7 goes eol, at that point we should transition the python2 maintenance involvement from the core developers from active to passive.
Sounds good, we should prepare a section in the docs with that outline, and put it in our sidebar. What is not clear to me though is when we will start the python2-maintenance branch. As I understand it, the maintenance branch would go live once we make the first python 3 only release, correct? When do you think we should plan for that to happen? End of 2020 or sooner?
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
Hi Bruno, Am Montag, den 01.10.2018, 08:13 -0300 schrieb Bruno Oliveira:
Hi Ronny,
On Mon, Oct 1, 2018 at 5:01 AM RonnyPfannschmidt < opensource@ronnypfannschmidt.de> wrote:
Hi Everyone,
the python3 support poll has run its on
https://twitter.com/ossronny/status/1043837215175057408
The results have a interesting shape.
37% now
09% with 3.4 mid 2019
38% with the python 2.7 eol
16% a year after py 2.7 eol
468 votes in the final result.
Its my belief that a increase of the of the sample size wouldn't have
changed the outcome of the poll.
I observed it rather quickly normalizing into that shape.
I consider the 2 peaks important indications of the desires and
considerations of people.
By my own wishes i'd just go ahead and drop python2 as well, but i don't
consider 37% of the community sample to be enough to warrant something
with such drastic effects right now.
When summing up with the ~9% of the "with 3.4" and also weighting in the
larger time-frame and my impression about the rounding twitter uses we
get a subjective number of ~49%+-1%.
Which i consider a good context for dropping the "general support for
python3".
So together with support for python3.4 i want pytest to drop support for
python2 for the general development.
As for maintenance branches for python2 - i proposed the setup in an
earlier mail and i would like to make a basic outline for its support.
the pytest core developers should actively support, maintain and
backport to this branch until python2.7 goes eol,
at that point we should transition the python2 maintenance involvement
from the core developers from active to passive.
Sounds good, we should prepare a section in the docs with that outline, and put it in our sidebar.
What is not clear to me though is when we will start the python2- maintenance branch. As I understand it, the maintenance branch would go live once we make the first python 3 only release, correct? When do you think we should plan for that to happen? End of 2020 or sooner?
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.-- Ronny
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
On Mon, Oct 1, 2018 at 8:22 AM Ronny Pfannschmidt < opensource@ronnypfannschmidt.de> wrote:
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,.
-- Ronny
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
participants (3)
-
Bruno Oliveira -
Ronny Pfannschmidt -
RonnyPfannschmidt