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. Different downstreams have different cadences. I can only speak for Debian, which has a release-when-ready policy, and Ubuntu, which has strictly timed releases. When the Python release aligns nicely with Ubuntu's LTS releases, we can usually manage the transition fairly well because we can allocate resource way ahead of time. (I'm less concerned about Ubuntu's mid-LTS 6 month releases.) For example, 3.6 final will come out in December 2016, so it'll be past our current 16.10 Ubuntu release. We've pretty much decided to carry Python 3.5 through until 17.04, and that'll give us a good year to make 18.04 LTS have a solid Python 3.6 ecosystem. Projecting ahead, it probably means 3.7 in mid-2018, which is after the Ubuntu 18.04 LTS release, so we'll only do one major transition before the next LTS. >From my perspective, that feels about right. Cheers, -Barry _______________________________________________ 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
