Shortening the Python release schedule
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.
![[Łukasz Langa]](https://static.lwn.net/images/2018/pls-langa-sm.jpg "Łukasz Langa")
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.
| Index entries for this article | |
|---|---|
| Conference | Python Language Summit/2018 |
| Python | Release model |
Posted May 23, 2018 16:07 UTC (Wed)
by Otus (subscriber, #67685)
[Link] (8 responses)
(Unless it's a personal project in which case I can use them even while 3.X is still in beta.)
I'd rather see less frequent stable releases, with usable betas and features that see real world testing before they are set in stone. That means fewer versions to think about when e.g. wanting to support a large set of distros until their EOL.
Posted May 23, 2018 16:52 UTC (Wed)
by smurf (subscriber, #17840)
[Link]
Posted May 23, 2018 18:23 UTC (Wed)
by tlamp (subscriber, #108540)
[Link] (6 responses)
The problem with this is: once people start using it in the wild it's more or less set in stone, you cannot really break with production stuff.
Posted May 23, 2018 18:55 UTC (Wed)
by jhoblitt (subscriber, #77733)
[Link] (5 responses)
Posted May 23, 2018 22:30 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link] (1 responses)
It's far better to have two distinct states: "feature present" and "feature not present" rather than a plethora of "present", "present, but broken", "present, but incompatible with the next version".
Posted May 24, 2018 23:04 UTC (Thu)
by smurf (subscriber, #17840)
[Link]
Posted May 24, 2018 18:00 UTC (Thu)
by excors (subscriber, #95769)
[Link] (2 responses)
Vaguely related to this: Around the time of HTML5, web browser developers realised that standards were good and it was a bad idea to pollute the global namespace with their own proprietary experimental features, so they used vendor prefixes to make it clear they were non-standard and not safe to be relied on by web sites, with the idea that eventually they'd be improved and standardised (based on experience from the experimental implementations) and have the prefixes removed. But it turns out that many web developers are irresponsible and will happily rely on those prefixed features in real production web sites, because all they care about is that it works today on their favourite browser, and then users of other browsers (or other versions of the same browser) blame their browser when sites look broken. That situation ends up with e.g. Firefox implementing webkit-prefixed features. I guess the conclusion is: don't give developers a useful feature and then tell them not to use it, because they'll use it anyway, and either you'll have to support it forever or you'll go through the same pain as with any other compatibility-breaking change. "Experimental" and "deprecated" are meaningless.
Posted May 24, 2018 18:13 UTC (Thu)
by jhoblitt (subscriber, #77733)
[Link]
Posted May 24, 2018 23:00 UTC (Thu)
by smurf (subscriber, #17840)
[Link]
No such problems exist with Python versioning.
Posted May 23, 2018 16:56 UTC (Wed)
by smurf (subscriber, #17840)
[Link] (2 responses)
Posted May 23, 2018 19:09 UTC (Wed)
by jhoblitt (subscriber, #77733)
[Link]
My experience, in a scientific computing environment, has been that the system python is primary used by the system itself and perhaps a few small user scripts but anything 'serious' uses a 3rd party interpreter. In my $day_job env that is mostly a mix of miniconda (lightweight default package set version of anaconda) and the rh-python36 scl.
In fact, its often the same pattern for node, ruby, and even perl5. Distro versions either move too slowly or are excessively disjoint between major distros.
Posted May 25, 2018 12:15 UTC (Fri)
by azumanga (subscriber, #90158)
[Link]
It's that inevitably a whole bunch of programs that use Python are going to get broken in obvious, or subtle, ways, and they all need testing and debugging. That's harder to automate.
Posted May 23, 2018 21:25 UTC (Wed)
by cyperpunks (subscriber, #39406)
[Link] (1 responses)
It should slow down, at least a 3 years cycle.
Posted May 24, 2018 1:46 UTC (Thu)
by willy (subscriber, #9762)
[Link]
Shortening the Python release schedule
Shortening the Python release schedule
Shortening the Python release schedule
If you argue that they simply shouldn't not guarantee any API/Functional stability then I'd say that no one will really use it at a scale where it would become obvious if the new features and changes do actually well, it's a catch 22.
Shortening the Python release schedule
Shortening the Python release schedule
Shortening the Python release schedule
Shortening the Python release schedule
Shortening the Python release schedule
Shortening the Python release schedule
Work required for new major releases
Work required for new major releases
Work required for new major releases
Shortening the Python release schedule
Shortening the Python release schedule