On 25.01.2017 13:30, Antoine Pitrou wrote:
Le 25/01/2017 à 10:19, M.-A. Lemburg a écrit :
All that said, I believe a having a Python 2.7 style long support version for Python 3 would be nice and have a stabilizing effect which our user base would appreciate.
Trying to enforce such a level of commitment (if we're talking 5+ years of bugfix maintenance on an increasingly divergent codebase) in the already controversial PEP 407 is probably not a good idea. A separate PEP is in order.
This is not about enforcing commitment, it's about opening up our release process to be able to apply fixes on such an LTS beyond what we'd normally do.
I'm pretty sure we can find core developers or attract new ones who'd be happy to be able to help fix issues in Python releases they use in their day job rather than work on releases which they won't be able to use in their day for at least another few years due to company policies.
I also believe that the PSF should start stepping up and invest some money into helping with Python support. A lot of money is being spent on community work, but hardly any on development work at the moment.
By doing so, the PSF could also attract more sponsors, since sponsoring would then have a real tangible benefit to the sponsors.
We'd just say: this is our new LTS release (e.g. Python 3.7) and then move on until we're confident again that the feature set has stabilized enough to create a new LTS release.
In practice you wouldn't just "move on" but have to maintain that LTS release (which is the whole point). If we're talking something past the 2 years timerange, you can't just impose that on all core developers, so you need a subgroup of maintainers dedicated to that LTS release.
See above; this is about opening doors and lifting restrictions.