On 6 July 2016 at 03:44, Barry Warsaw <barry@python.org> wrote:
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.
This aligns pretty well with Fedora's plans - the typical Fedora release dates are May & November, so we will stick with 3.5 for this year's F25 release, while the Fedora 26 Rawhide branch is expected to switch to 3.6 shortly after the first 3.6 beta is released in September. The results in Rawhide should thus help with upstream 3.6 beta testing, with the full release of F26 happening in May 2017 or so.
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.
Likewise - 24 months is a bit too slow in getting features out, 12 months expands the community version support matrix too much, while 18 months means that even folks supporting 5* year old LTS Linux releases will typically only be a couple of releases behind the latest version. Cheers, Nick. * For folks that don't closely follow the way enterprise Linux distros work, the '5' there isn't arbitrary - it's the lifecycle of Ubuntu LTS releases, and roughly the length of the "Production 1" phase of RHEL releases (where new features may still be added in point releases). Beyond the 5 year mark, I don't think it's particularly reasonable for people to expect free community support, as even Red Hat stops backporting anything other than bug fixes and hardware driver updates at that point. Regardless of your choice of LTS platform, newer versions will be available by the time your current one is that old, so "I don't want to upgrade" is a privilege people can reasonably be expected to pay for. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia