[Python-Dev] What is the rationale behind source only releases?

Ned Deily nad at python.org
Wed May 16 07:06:52 EDT 2018


On May 16, 2018, at 00:35, Alex Walters <tritium-list at sdamon.com> wrote:
> In the spirit of learning why there is a fence across the road before I tear
> it down out of ignorance [1], I'd like to know the rationale behind source
> only releases of cpython.  I have an opinion on their utility and perhaps an
> idea about changing them, but I'd like to know why they are done (as opposed
> to source+binary releases or no release at all) before I head over to
> python-ideas.  Is this documented somewhere where my google-fu can't find
> it?

The Python Developer's Guide has a discussion of the lifecycle of cPython releases here:

https://devguide.python.org/#status-of-python-branches

The ~short answer is that we produce source+binary (Windows and macOS binary installers) artifacts for release branches in "bugfix" (AKA "maintenance") mode (currently 3.6 and 2.7) as well as during the later stages of the in-development phase for future feature releases ("prerelease" mode) (currently 3.7); we produce only source releases for release branches in "security" mode.

After the initial release of a new feature branch (for example, the upcoming 3.7.0 release), we will continue to support the previous release branch in bugfix mode for some overlapping period of time.  So, for example, the current plan is to support both 3.7.x and 3.6.x (along with 2.7.x) in bugfix mode, releasing both source and binary artifacts for about six months after the 3.7.0 release.  At that point, 3.6.x will transition to security-fix-only mode, where we will only produce releases on an as-needed basis and only in source form.  Currently, 3.5 and 3.4 are also in security-fix-only mode.  Eventually, usually five years after its initial release, a release branch will reach end-of-life: the branch will be frozen and no further issues for that release branch will be accepted nor will fixes be produced by Python Dev.  2.7 is a special case, with a greatly extended bugfix phase; it will proceed directly to end-of-life status as of 2020-01-01.

There is more information later elsewhere in the devguide:

https://devguide.python.org/devcycle/

and in the release PEPs linked in the Status of Python Branches section.

Hope that helps!

--
  Ned Deily
  nad at python.org -- []



More information about the Python-Dev mailing list