[Python-Dev] release cadence (was: Request for CPython 3.5.3 release)

[Nick Coghlan]

On 4 July 2016 at 06:22, Brett Cannon <brett at python.org> wrote:
> [forking the conversation since the subject has shifted]
>
> On Sun, 3 Jul 2016 at 09:50 Steve Dower <steve.dower at python.org> wrote:
>>
>> Many of our users prefer stability (the sort who plan operating system
>> updates years in advance), but generally I'm in favour of more frequent
>> releases.
>
>
> So there's our 18 month cadence for feature/minor releases, and then there's
> the 6 month cadence for bug-fix/micro releases. At the language summit there
> was the discussion kicked off by Ned about our release schedule and a group
> of us had a discussion afterward where a more strict release cadence of 12
> months with the release date tied to a consistent month -- e.g. September of
> every year -- instead of our hand-wavy "about 18 months after the last
> feature release"; people in the discussion seemed to like the 12 months
> consistency idea.

While we liked the "consistent calendar cadence that is some multiple
of 6 months" idea, several of us thought 12 months was way too short
as it makes for too many entries in third party support matrices. I'd
also encourage folks to go back and read the two PEPs that were
written the last time we had a serious discussion about changing the
release cadence, since many of the concerns raised then remain
relevant today:

* PEP 407 (faster cycle with LTS releases):
https://www.python.org/dev/peps/pep-0407/
* PEP 413 (separate stdlib versioning):
https://www.python.org/dev/peps/pep-0413/

In particular, the "unsustainable community support matrix" problem I
describe in PEP 413 is still a major point of concern for me - we know
from PyPI's download metrics that Python 2.6 is still in heavy use, so
many folks have only started to bump their "oldest supported version"
up to Python 2.7 in the last year or so (5+ years after it was
released). People have been a bit more aggressive in dropping
compatibility with older Python 3 versions, but it's also been the
case that availability and adoption of LTS versions of Python 3 has
been limited to date (mainly just the 5 years for 3.2 in Ubuntu 12.04
and 3.4 in Ubuntu 14.04 - the longest support lifecycle I'm aware of
after that is Red Hat's 3 years for Red Hat Software Collections).

The reason I withdrew PEP 413 as a prospective answer to that problem
is that I think there's generally only a limited number of libraries
that are affected by the challenge of sometimes getting too old to be
useful to cross-platform library and framework developers (mostly
network protocol and file format related, but also the ones still
marked as provisional), and the introduction of ensurepip gives us a
new way of dealing with them: treating *those particular libraries* as
independently upgradable bundled libraries where the CPython build
process creates wheel files for them, and then uses ensurepip's
internally bundled pip to install those wheels at install time, even
if pip itself is left out of the installation.

In the specific case that prompted this thread for example, I don't
think the problem is really that the standard library release cadence
is too slow in general: it's that "pip install --upgrade asyncio"
*isn't an available option* in Python 3.5, even if you're using a
virtual environment.

For other standard library modules, we've tackled that by letting
people do things like "pip install contextlib2" to get the newer
versions, even on older Python releases - individual projects are then
responsible for opting in to using either the stdlib version or the
potentially-newer backported version.

However, aside from the special case of ensurepip, what we've yet to
do is ever make a standard library package *itself* independently
upgradable (such that the Python version merely implies a *minimum*
version of that library, rather than an exact version). Since it has
core developers actively involved in its development, and already
provides a PyPI package for the sake of Python 3.3 users, perhaps
"asyncio" could make a good guinea pig for designing such a bundling
process?

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia