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).