[python-committers] Pace of change for Python 3.x

[Antoine Pitrou]

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.