Le 25/01/2017 à 10:19, M.-A. Lemburg a écrit :
You should take a look at this old deferred PEP: https://www.python.org/dev/peps/pep-0407/
I don't understand the reasoning behind that PEP. With the proposed timing, those "LTS" releases would be no different than what we have today.
The only effect of the PEP would be to do releases more often,
That's indeed the main motivation: allow shipping changes faster to the subset of users who are ok with a shorter support cycle (which has the side-effect of making those changes tested in the wild earlier).
which then results in using up minor release version numbers much too fast to give the impression of a stable programming system.
People with such psychological bias can simply use said "LTS" releases, which would provide the same level of stability as today's feature releases.
FWIW: I don't consider a release which is supported for just two years a long term support release.
The vocabulary can be changed if that's a concern :-)
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.
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.
Regards
Antoine.