More frequent Python releases?

Python has followed an 18-month release cycle for many years now; each new 3.x release comes at that frequency. It has worked well, overall, but there is interest in having a shorter cycle, which would mean that new features get into users' hands more quickly. But changing that longstanding cycle has implications in many different places, some of which have come up as part of a discussion on switching to a cycle of a different length.

Łukasz Langa, who is the release manager for the upcoming 3.8 release, as well as the manager for the date-to-be-determined release of 3.9, has proposed PEP 596 ("Python 3.9 Release Schedule (doubling the release cadence)"). As its name would imply, the PEP proposes halving the current release cycle to nine months, which would make the 3.9 release happen in June 2020. As described in PEP 569 ("Python 3.8 Release Schedule"), the Python 3.8 release is slated for October of this year; it is in beta at this point, so no new features can be added. The beta release also marks the start of development for the next release, so work on 3.9 has already begun. With that overlap, a nine-month cycle would actually allow seven or eight months for feature development and four or five months for shaking out the bugs from the first beta release on.

As proposed, each release would be supported with bug fixes for roughly 12 months, then it would move to security-fixes-only mode for the following four years. The idea is to get new features out to users sooner, rather than have them languish in an under-development release for a year or more. The overall development pace of the language would not change, but the delta for each release would be smaller, thus provide less risky upgrades. As the PEP puts it:

Reaction

The reaction to the overall idea was positive, though several suggested that making releases every 12 months would be better. Nick Coghlan said:

Guido van Rossum agreed: "It makes the (approximate) release cadence easier to remember. 'New Python releases come out in <month>.'" But Nathaniel J. Smith suggested considering a six-month cycle, similar to what Ubuntu does. That would include a "long-term support" (LTS) version every so often, perhaps every third or fourth release. The PEP also mentions the possibility of an LTS release, since shortening the bug-fix period to 12 months is helpful to Python developers but may be inconvenient for users.

A problem with the six-month idea is that the number of active releases being supported will be higher. As Antoine Pitrou pointed out, that cost is not only borne by the core developers; third-party packages of various sorts will need to also support multiple concurrent releases. Smith said that he was envisioning that most releases would only be supported until shortly after the next release, except for the LTS versions. He ended up drawing a picture comparing the current system, the nine-month cycle as proposed in the PEP, and his idea for a six-month cycle.

The six-month idea did not garner much support; even Smith is not really advocating it. For one thing, dropping support after roughly nine months means that users have to either get on an upgrade treadmill or stick with an LTS release. Many Linux distributions will likely stick to LTS versions, though they may backport some features and fixes. Fast-moving distributions (e.g. Fedora), would be stuck in a situation where the non-LTS versions are only supported for significantly less time than the distribution, as Petr Viktorin pointed out:

Viktorin said that Fedora would likely have to skip some releases, perhaps only using LTS releases, under the six-month plan; the nine-month cycle proposed by the PEP would also be awkward, he thought.

The steering council discussed the cadence of releases at its June 11 meeting. As reported by Coghlan, the council is "definitely sympathetic to the idea", but normally the schedule PEP is informational in nature; it is maintained by the release manager and not formally adopted like other PEPs. The council would like to see the cadence proposal as a "regular" PEP that requires review and approval by the core developers—ultimately, it will be decided by the council or its delegate. Coghlan personally thinks that using PEP 596 as that PEP would be fine; the schedule PEP could come later, once a determination is made.

In a lengthy message of his own opinions (not necessarily those of the rest of the steering council), he said that the yearly cadence aligns nicely with events in the ecosystem (e.g. PyCon US and the annual core developer sprints). But he is concerned of the extra burden the existing support schedule would impose. Right now, Python releases are supported with bug fixes until roughly six months after the next release (two years total) and then get security fixes until they are five years old or so. Coghlan suggested something rather different:

That would result in "a larger support matrix than today, but it's not dramatically larger the way it would be if we did a standard lifecycle release every year". Van Rossum's personal opinion is that a faster release cycle is desirable and paring down the support matrix is needed, but he is not in favor of an even-odd switch between the standard and minimal lifecycles.

Smith pointed out that the Django web framework does something similar, but that it still requires some knowledge to determine whether a release is short-lived or not. But he wondered if bumping the major release number would cause problems for programs that have checks like:

    if sys.version_info[0] == 3:
        ...

Coghlan suggested a variation of his earlier idea that would allow for backward-compatible feature additions to point releases (X.Y.1 and X.Y.2) for 12 months, then bug fixes for 12 months, followed by three years of security-only fixes. Brett Cannon thought that the numbering scheme just made the problem Van Rossum raised worse; "you need innate knowledge of what those versions represent in order to know if there's new features or if it's just a bugfix release". To Cannon, that suggests moving to Semantic Versioning (semver):

Cannon was concerned that people were getting too hung up on the idea that switching to Python 4 would worry users: "I say jump to Python 10 and basically start fresh with our numbering scheme". Coghlan did not think users would really wonder about which releases had new features and which were simply fixing bugs, but Paul Moore strongly disagreed: "I'm with Guido that you shouldn't need to ask an expert to understand the significance of a version number."

Coghlan created PEP 598 ("Introducing minor feature releases") to describe his ideas, but the reaction so far does not seem favorably inclined toward changing the interpretation of the point-release number. As Van Rossum put it:

Cannon agreed that a yearly cadence made sense and that no change to the version-number scheme was really necessary. He is also a member of the steering council, so that would seem to indicate that at least two of the five members are leaning that way. Most of the comments—Langa has been mostly silent since posting the PEP—seem to be assuming that the 12-month cycle will "win" over the proposed nine-month cycle, but any change will be somewhat tumultuous in the ecosystem. It seems unlikely, but possible, that the steering council could settle on "no change", at least for 3.9. But we are still quite early in the cycle for 3.9; if Langa updates his PEP to a 12-month cycle, it might well be adopted soon.