The primary benefit from subscribing to LWN is helping to keep us publishing, but, beyond that, subscribers get immediate access to all site content and access to a number of extra site features. Please sign up today!
The Python release cycle has an 18-month cadence; a new major release (e.g. Python 3.7) is made roughly on that schedule. But Łukasz Langa, who is the release manager for Python 3.8 and 3.9, would like to see things move more quickly—perhaps on a yearly cadence. In the first session after lunch at the 2018 Python Language Summit, Langa wanted to discuss that idea.
Before he got started, though, he noticed his name in Larry Hastings's schedule-display application started with the dreaded ▯ rather than Ł. That, he said with a grin, is the story of his life. Hastings dryly suggested that the font he was using predates the addition of the Ł character to Unicode, which elicited a fair bit of laughter.
Langa showed a "boring graph" that indicated the length of time that each release spent in each phase of its development. It showed that the developers spend more than a year creating the features that go into a particular major release as measured from when the branch opens until the first beta release. That means that the project is sitting on changes, which means that people cannot use them, for a long time.
He showed the proposed schedule for 3.8, which has feature development running from January 2018 (first 3.7 beta) until May 2019 (the first 3.8 beta). That puts the release of 3.8 in October 2019. "I think we can do better", Langa said.
So he would like to accelerate the development so that major releases are done yearly. He would also like to see point releases done monthly. Currently, there are release candidates for the point releases, but he thinks that no one really looks at those. Several in the audience disagreed, though. Hastings, who is the release manager for 3.4 and 3.5, said that he has had bugs reported against 3.[45].x release candidates; some caused him to do a second candidate release. Langa said that his goal is to get fixes for "stuff that is broken" into the hands of users faster.
Barry Warsaw asked if Langa was suggesting that Python move to time-based releases. It would be more predictable, which has some advantages. But Ned Deily, who is the release manager for 3.6 and 3.7, said that it makes sense to differentiate between feature releases (3.6) and maintenance releases (3.6.1). For 3.6, maintenance releases have been pretty much time-based; he plans to do the same for 3.7. For the feature releases, he has pushed for a yearly schedule, but Fedora and Ubuntu push back, he said.
Nick Coghlan said that frequent feature releases can cause distributions and other projects to have to support (and test) more releases simultaneously. If a distribution is trying to support several of its own releases, it might currently be testing with three or more Python versions; making the Python releases yearly increases that testing burden. It would also affect projects like NumPy and Django that need to ensure they work on a wide range of current Python releases.
A NumPy developer agreed that it would increase the amount of testing that needed to be done, but said it was "not completely undoable". Warsaw said that it takes a lot of work, for a lot of different projects, to roll out a new version of Python. Christian Heimes suggested that moving to yearly releases could be coupled with creating a long-term support (LTS) version of Python. For example, every other release could be an LTS.
But Brett Cannon wondered what LTS would mean and what guarantees the project would be making about that kind of release. Would there be no new features and no deprecations over the LTS time frame? Langa noted with amusement that some of his colleagues at Facebook claim that Python 2 never broke backward compatibility—that was met with a loud round of laughter. But those developers have been working with Python 2.7 for nine years at this point, so they have not seen a backward compatibility break, he said.
Overall, the idea of shortening the cycle and adding an LTS into the mix did not seem to run into any strong opposition. Langa volunteered to support 3.9 for five years as an LTS. There will presumably need to be some more discussion of the development cycle and what an LTS actually is—something that seems likely to happen on the python-dev mailing list in the not-too-distant future.
(Log in to post comments)