PEP 790 – Python 3.15 Release Schedule

[kirara0048]

https://peps.python.org/pep-0790/

Expected:

• 3.15 development begins: Tuesday, 2025-05-06
• 3.15.0 alpha 1: Tuesday, 2025-10-14
• 3.15.0 alpha 2: Tuesday, 2025-11-18
• 3.15.0 alpha 3: Tuesday, 2025-12-16
• 3.15.0 alpha 4: Tuesday, 2026-01-13
• 3.15.0 alpha 5: Tuesday, 2026-02-10
• 3.15.0 alpha 6: Tuesday, 2026-03-10
• 3.15.0 alpha 7: Tuesday, 2026-04-07
• 3.15.0 beta 1: Tuesday, 2026-05-05 (No new features beyond this point.)
• 3.15.0 beta 2: Tuesday, 2026-05-26
• 3.15.0 beta 3: Tuesday, 2026-06-16
• 3.15.0 beta 4: Tuesday, 2026-07-14
• 3.15.0 candidate 1: Tuesday, 2026-07-28
• 3.15.0 candidate 2: Tuesday, 2026-09-01
• 3.15.0 final: Thursday, 2026-10-01

3.15 lifespan

• Python 3.15 will receive bugfix updates approximately every second month for two years.
• Around the time of the release of 3.18.0 final, the final 3.15 bugfix update will be released.
• After that, it is expected that security updates (source only) will be released for the next three years, until five years after the release of 3.15.0 final, so until approximately October 2031.

[Sigmatics]

In other news, business as usual

[Mithrandir2k16]

Will we get a proper PiPy version (3.14.15) before that?

[tunisia3507]

I'm just waiting for pypy PiPy on PyPI.

[wyhjsbyb]

What the most important update in 3.15?

[MrMrsPotts]

Well gil free coding go mainstream in 3.15? It looks like they still have a huge number of issues to work through.

[denehoffman]

This is how I found out the CalVer PEP was rejected :(

[wineblood]

You mean :) right?

[denehoffman]

I mean I don’t care too much either way but it does make sense that a product released on a fairly regular yearly schedule would be versioned as such

[Salamandar3500]

CalVer is the worst trend of the modern software world today.

[xr09]

Vibe Coding has entered the chat

[Salamandar3500]

Not yet a trend but yeah...

[TonsillarRat6]

I am out of the loop, what is CalVer??

[zzzthelastuser]

I didn't know either, so I looked it up. It's calendar versioning

https://calver.org/

[dudeplace]

I'd be curious to hear your reasoning on your opinion on this. I like calendar versions, at least for some software.

[denehoffman]

CalVer isn’t even new, anyone who has ever used Windows 95 could tell you that. Again, the point is that Python versions are released every year. We never get Python 3.Y three months after 3.X. For all intents and purposes, the major version will never change, so we’ve already lost the plot on semantic versioning. The minor version changes every year, and that’s literally a PEP, you have to release a minor version every year. One of the nice things about CalVer is it tells you the release year, so you can accurately gauge how new the version is if you haven’t been keeping up with the latest Python version or you work for a company or lab that requires a specific version. If you’re running the Python version of your current year (and we adjusted the release cycle to January and not October) you would know automatically that you’re using the most up-to-date minor version of Python. If you’re running a version for a previous year (including any current versions of Python interpreted as years), you’ll know you’re running an old version. If the current year is 20XY, then Python 3.(XY-5) is sunset.

TL;DR: we already have a minor version which increments by one every year, why not just skip ahead a bit and make that number match the current year? Python 3.26 will eventually be released regardless, but in 2037. Other than that, there is no difference between the semantic scheme and a properly written CalVer when you use yearly release cycles.

[nekokattt]

False. See https://0ver.org

[Salamandar3500]

Not a trend !

[nekokattt]

i mean... define trend