On 05.07.2016 21:11, Brett Cannon wrote:
On Tue, 5 Jul 2016 at 10:45 Barry Warsaw <barry@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. Matthias