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

Paul Moore p.f.moore at gmail.com
Sun Jul 3 16:43:32 EDT 2016


On 3 July 2016 at 21:22, Brett Cannon <brett at python.org> wrote:
> Topic 2
> =======
> Independent releases of the stdlib could be done, although if we break the
> stdlib up into individual repos then it shifts the conversation as
> individual modules could simply do their own releases independent of the big
> stdlib release. Personally I don't see a point of doing a stdlib release
> separate from CPython, but I could see doing a more frequent release of
> CPython where the only thing that changed is the stdlib itself (but I don't
> know if that would even alleviate the RM workload).

The one major downside of independent stdlib releases is that it
significantly increases the number of permutations of things 3rd
parties have to support. It can be hard enough to get a user to report
the version of Python they are having an issue with - to get them to
report both python and stdlib version would be even trickier. And
testing against all the combinations, and deciding which combinations
are supported, becomes a much bigger problem.

Furthermore, pip/setuptools are just getting to the point of allowing
for dependencies conditional on Python version. If independent stdlib
releases were introduced, we'd need to implement dependencies based on
stdlib version as well - consider depending on a backport of a new
module if the user has an older stdlib version that doesn't include
it.

Changing the principle that the CPython version is a well-defined
label for a specific language level and stdlib, is a major change with
very wide implications, and I don't see sufficient benefits to justify
it. On the other hand, simply decoupling the internal development
cycles for the language and the stdlib (or independent stdlib
modules), without adding extra "release" cycles, is not that big a
deal - in many ways, we do that already with projects like asyncio.

Paul


More information about the Python-Dev mailing list