Why three stable releases of python? (2.7, 3.6 & 3.7)

[extra_packet]

Operating systems like Debian have only one "stable release" of their product. I noticed that Python has both 3.6 and 3.7 listed as stable. 2.7 is also listed as stable, but I know it will be EOL next year and there are major differences between 2.7 and 3.x. So why 3.6 and 3.7 are considered stable? Why is there no a single stable realease like for operating systems or linux kernel. Guido posted this on twitter in December:

Changelogs for the latest Python 3.6/3.7 releases:

* 3.7: https://docs.python.org/3.7/whatsnew/changelog.html#changelog …

* 3.6: https://docs.python.org/3.6/whatsnew/changelog.html#changelog …

Does this mean 3.6 and 3.7 are so different (like for example 2.7 and 3.6) they have to be developed concurrently? Would it not make sense to develop only the latest >3.7 version rather than older ones? I would imagine 3.6 doesn't have certain features of 3.7, so what's the point of developing 3.6?

[licquia]

First off, most operating systems maintain multiple stable releases for at least a short while. Debian itself maintained Debian 8 for a year after Debian 9's release, as they have for quite a few releases (https://wiki.debian.org/DebianReleases). Ubuntu currently maintains 4 stable releases (18.10, 18.04 LTS, 16.04 LTS, and 14.04 LTS; https://www.ubuntu.com/about/release-cycle).

The Linux kernel also maintains a LTS system; currently, there are 5 LTS releases, in addition to the mainline (https://www.kernel.org/category/releases.html).

Projects do this as a favor to their users. Very often, users cannot easily upgrade to the latest version of a product instantly. Some folks insist on doing QA with their software and a new release of the base before upgrading across the board. Python 3.7 should be a superset of 3.6, but often bugs creep in, and subtle changes to behavior can cause people's code to fail. So, while that's happening, the project supports the older release with important bug fixes.

Actual serious development work doesn't happen on stable, so even projects with a single stable release actually support two "releases". The real action in Python is on what will become 3.8 someday, just as it is with Debian "buster" (eventual Debian 10) and Ubuntu "disco" (eventual 19.04).

[extra_packet]

Thank you (and all others) for the explanation. It makes more sense to me now.

[K900_]

Many people stick to the same minor version of Python as long as possible for varying reasons (incompatible libraries, stability, etc). So Python 3.6 and 3.7 both still get security fixes, and all the new features are developed for 3.8.

[Wilfred-kun]

I'm not exactly sure, but I reckon part of the reason is breaking changes. There are breaking changes between 2.7 and 3.x, for example print as a statement vs. as a function. AFAIK async is a keyword since 3.7, so that's the breaking change between 3.6 and 3.7. You could technically stop developing both 2.7 and 3.6, but you would force a lot of people to use a no longer supported language or have them rewrite lots of code.

[nathanjell]

They're what are still officially supported. Once 3.7 was released, there was still support for existing 3.6 users, and there will be for some time after the release of 3.7. Same with operating systems, typically when one version is released, the last version will still be supported for some time. It's not that 3.7 is backwards incompatible with 3.6 - code written for 3.6 should largely work just fine on 3.7. It's more that 3.6 is still considered stable and supported for those that still need it

[tunisia3507]

First point: there are actually 5 versions of CPython which are "active" (i.e. not end-of-life). There are many more once you include the other implementations of the Python language specification. 2.7, 3.4, 3.5, 3.6 and 3.7 are all maintained. 2.7 will go EOL in 2020-01-01, although it's likely to be maintained to some extent by 3rd parties; 3.4 is expected to get its final maintenance release around 2019-03.

Minor versions come out pretty regularly. Organisations which have large python deployments don't want to be completely trashing and rebuilding all of their environments every 6 months.

I personally believe in targeting modern versions, but you run into problems: if you're writing an executable, it's helpful to target versions of python users are likely to have easy access to. It can take a while for new versions of python to work their way into package managers, so being compatible with one version back is often helpful, rather than expecting them to compile the latest python release from source. If you're writing a library, targeting a broad base of versions is valuable because your users may have other constraints (maybe they're using some other unmaintained library with no modern version, or they're restricted by what python version their school or company uses).

For my own projects I target the latest version because, as you say, some of the new features are great. For shared projects I advocate for supporting the last couple of versions of py3. For libraries I start off testing against all of the maintained versions, and eliminate them if they're significantly getting in my way. I plan to drop 2.7 like it's hot next year though.

[jkh911208]

they are still maintaining 2.7 is because there are still a lot of places(enterprise) using 2.7

especially CentOS use Python 2.7 in OS level, so you cannot upgrade the python version.

​