Does every year python develop a new 3.x version?

Python Help
1

In Status of Python versions this page, I found python develop one 3.x version every year:
3.8 2019-10-14
3.9 2020-10-05
3.10 2021-10-04
3.11 2022-10-24
3.12 2023-10-02
3.13 2024-10-01
Is it the truth that python mantainer will plan a 3.x version every year？ Are there any considerations that python need a new 3.x version?

2

Yes, that is currently the case, starting with Python 3.9. See PEP 602 – Annual Release Cycle for Python | peps.python.org for some more information

3

I think it has worked out very well.

4

There isn’t a real meaningful question of “need”. There is a constant stream of ideas for ways to improve Python, and some of them are chosen for implementation. Some things can be considered bugfixes that go in a patch release; others are disruptive enough that they only make sense for a new minor version. (Python 4 would, in principle, be for major changes that deliberately break backwards compatibility, like what happened with 3 vs 2; there are currently still no plans for this to ever happen.)

Rather than try to make logical groups of these changes for each update (or, indeed, update the minor version number for each new feature - there are probably some software projects out there which do this strictly), Python has adopted the principle of having a release cadence. This means having a specific planned date for each new minor release; a schedule built around making sure that this happens; and choosing features to include in new minor versions, based on what’s feasible to do in that time frame.

This is a very common and standard way for major software projects to organize - especially ones where there are a lot of users who can’t easily update to the newest version immediately all the time, so that the developers are also constantly working on patch release for older minor versions. It’s also normal, under this scheme - like Python does - to have set periods where certain kinds of maintenance will be done on the older minor-version branches. This is also part of the “release cadence”.

In the case of Python, the current cadence involves a new release every year, as you found; an “active support” period of 1.5 years (but this is planned to increase to 2 years for Python 3.13 - and presumably going forward from there) where ordinary bugs are fixed; and a “security support” period of 5 years (in total, including the active support period) where security issues are fixed. Thus, at any given time, there are generally five minor-version branches of Python under maintenance (currently, that’s 3.8 through 3.12) and one or two in development (currently only 3.13; 3.14 will likely start in May). Security support for 3.8 will be dropped approximately at the same time as the final release of 3.13.0.

For a few previous minor versions of Python, the release cadence was supposed to be every 1.5 years, but in practice this was a bit approximate. Further in the past, there was not always a system like this, to my understanding. As well, Python 2.7 got an extended support period due to the issues people had with migrating to 3.x. You can see some more information about the actual release dates with some nice formatting and summarization here; or check the complete list of historical releases on the downloads page on the main website. (The table under “Looking for a specific release?” scrolls all the way back to Python 2.0.1.)

2 Likes
5

New to Python, but here’s what I take into account.

  1. Will the new Python solve any specific problems for the user or programmer? If yes then consider updating it, but weight the costs of testing with the new version of Python.
  2. Are there features in the new Python you really would like to use? If yes, then consider updating.
  3. Does the new Python fix a security problem? Then consider updating Python.
  4. How many people does the upgrade affect? How many people use that Python for development? Consider the effect on other developers and work with them on the upgrade if an upgrade is needed.

Contact your IT department for more info on guidelines for upgrading Python, like when you do it, how often you do it, how you have to work with them to do the install, etc.

Somewhere around 2004 we did an OS upgrade (Solaris which is unix) which caused our Perl programs to round prices differently, which caused a massive screw up and 1000s of inaccurate prices. The OS upgrade changed a C library which Perl used. What a mess that was. And that was the point where I made my own round() function in my own library file.

6

All good questions, but I think question 0 is important:

  1. Do I care about upstream support? If yes, then upgrade (sooner rather than later).

All the other questions may discover reasons to delay upgrading, but every time a new version is released, support for an older version is dropped. It’s not too hard to upgrade from one minor version to the next (something I think the developers strive to accomplish precisely because of the difficulty of moving from Python 2 to Python 3), and it’s always going to be easier to upgrade from 3.x to 3.(x+1) than it will be to make a bigger jump later on.

7

What I recommend (and don’t implement yet but will going forward starting this fall):

  • If Python came with the operating system, don’t touch it aside from what the system updater/package manager/etc. recommends. Instead, when that Python version will leave security support, upgrade the operating system (presumably the upgraded version will use a newer Python version).

  • For everything else, just saddle up and install the versions as they come out. It’s not that hard (even if building from source) and it only happens once a year. Once it’s set up, arbitrarily many virtual environments can be easily created from there.

1 Like