On Tue, 5 Jul 2016 at 10:45 Barry Warsaw <ba...@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).
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
