[Python-Dev] release cadence

Matthias Klose doko at ubuntu.com
Fri Jul 8 08:08:35 EDT 2016

On 05.07.2016 21:11, Brett Cannon wrote:
> On Tue, 5 Jul 2016 at 10:45 Barry Warsaw <barry at python.org> wrote:
>> On Jul 04, 2016, at 10:31 AM, Nick Coghlan wrote:
>>> 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.
>> 18 months for a major release cadence still seems right to me.  Downstreams
>> and third-parties often have to go through *a lot* of work to ensure
>> compatibility, and try as we might, every Python release breaks
>> *something*.
>> Major version releases trigger a huge cascade of other work for lots of
>> other
>> people, and I don't think shortening that would be for the overall
>> community
>> good.  It just feels like we'd always be playing catch up.
> Sticking w/ 18 months is also fine, but then I would like to discuss
> choosing what months we try to release to get into a date-based release
> cadence so we know that every e.g. December and June are when releases
> typically happen thanks to our 6 month bug-fix release cadence. This has
> the nice benefit of all of us being generally aware of when a bug-fix
> release is coming up instead of having to check the PEP or go through our
> mail archive to find out what month a bug-fix is going to get cut (and also
> something the community to basically count on).

I like the 18 months cycle, because it's a multiple of six, which fits the
Ubuntu release cadence (as as I understand, the Fedora cadence as well).
Sometimes it might be ambitious to update reverse dependencies in the distro
within two months until the distro freeze, and two more months during the freeze
leading to a distro release, but such is life, and it's then up to distro
maintainers of LTS releases to prepare the distro for a new version with only
four months left.

My hope with time based releases is that also upstreams will start testing with
new versions more early when they can anticipate the release date.


More information about the Python-Dev mailing list