[shepardrtc]

Per the 3.6 release schedule[1], 3.6 was the stable branch until the final release of 3.7.0. After that, it was to receive two more bug fix releases and then switch over to security fixes. 3.7.0 final was released a few months ago, so this is the last bugfix release for 3.6.x. 3.7.0 is now considered "stable". However, 3.6.8 will still receive security fixes for anyone that is depending on it.

This is generally done for those who want "stable" releases with minimal bug fixes. The 3.7 branch has newer features and therefore, potentially more bugs.

If you want the latest stable version, get 3.7.0. If you want the latest version, get 3.7.2.

[1] https://www.python.org/dev/peps/pep-0494/

[phonon]

Why do you say 3.7.0 is more "stable" than 3.7.2?

3.7.2 is a maintenance release of the 3.7 series...I am not aware of anyone who considers 3.7.0 the version you should stay with.

[fromthestart]

How does that justify 4 different 3.x branches continually updated in the last year, from 3.4 to 3.7?

That still doesn't explain why it makes sense for python devs to be split among what, 4 different 3.x branches in the last year? I can understand keeping one stable LTS branch and one "up to date" branch, but the current system seems like a waste of resources and extra complexity, though I assume there's a good reason I'm not familiar with. For example, 3.4 .9 was released after 3.7.0. [1]

Maybe I'm just missing something about the numbering scheme?

1.https://www.python.org/downloads

[theptip]

> I can understand keeping one stable LTS branch and one "up to date" branch

If you did that then lots of distro packagers would just stay on the LTS until the next one comes along, and so you'd increase the number of users that are on older versions. With the selected approach, there is more work involved to backport a fix to the 4-5 supported versions, but this gives the benefit that OS distros can bump their Python versions more frequently, and so end users get updated Python3 features more often.

[ProblemFactory]

All Linux distributions and MacOS ship with Python, and many users of Python stick to the OS-provided version without installing the latest and greatest on their own.

For example, they might only upgrade major Python versions (3.x) once they migrate from Ubuntu 16.04 LTS to 18.04 LTS or even directly four years to 20.04 LTS. Whichever Python version is available by default there becomes the next Python LTS for them.

For now, all versions since 3.4 receive occasional security and bug fixes to make all of them are "stable". New features are only adopted with a major version (3.x) bump.

I have not heard of the Python community complaining about this being too much work - after all improvement work is only done in the latest version, old versions just get backported bug fixes.

[maxerickson]

I guess you aren't missing anything. They do security releases for 5 years after the release of a minor version:

https://devguide.python.org/devcycle/#security-branches

Arbitrary, but not senseless or anything.

If you drill into the security releases, they are pretty small patches backported from later releases, not a huge burden.

[_eht]

On the note of stability, it's interesting to see which Linux distributions ship with which versions. Debian Stretch for instance ships with 3.5.3-1 while Ubuntu 18.04 LTS runs 3.6.5-3.

I know some who would argue that Debian is generally the more stable server and Ubuntu more bleeding edge.

[praseodym]

Debian Stretch was released June 2017 and Ubuntu 18.04, well, in April 2018, so its not too surprising that they ship with different Python versions.

I do find it surprising that Linux distributions don’t always choose upstream LTS versions for their releases, it just feels like a big waste of effort to backport fixes across many versions.

[geezerjay]

> Debian Stretch was released June 2017

Actually, Debian Stretch was released in April 2015, and their general freeze was set at November 2016.

Debian spends about 4 years producing a stable release, which excels at stability at the expense of using software releases that are far from the bleeding edge.