<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Tue, 5 Jul 2016 at 10:45 Barry Warsaw <<a href="mailto:barry@python.org">barry@python.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Jul 04, 2016, at 10:31 AM, Nick Coghlan wrote:<br>
<br>
>While we liked the "consistent calendar cadence that is some multiple<br>
>of 6 months" idea, several of us thought 12 months was way too short<br>
>as it makes for too many entries in third party support matrices.<br>
<br>
18 months for a major release cadence still seems right to me.  Downstreams<br>
and third-parties often have to go through *a lot* of work to ensure<br>
compatibility, and try as we might, every Python release breaks *something*.<br>
Major version releases trigger a huge cascade of other work for lots of other<br>
people, and I don't think shortening that would be for the overall community<br>
good.  It just feels like we'd always be playing catch up.<br></blockquote><div><br></div><div>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).</div></div></div>