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

[Alex Walters]

> -----Original Message-----
> From: Paul Moore <p.f.moore at gmail.com>
> Sent: Wednesday, May 16, 2018 4:07 AM
> To: Alex Walters <tritium-list at sdamon.com>
> Cc: Python Dev <python-dev at python.org>
> Subject: Re: [Python-Dev] What is the rationale behind source only releases?
> 
> On 16 May 2018 at 05: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?
> >
> >
> > [1]: https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence
> 
> Assuming you're referring to the practice of no longer distributing
> binaries for patch releases of older versions of Python, the reason is
> basically as follows:
> 
> 1. Producing binaries (to the quality we normally deliver - I'm not
> talking about auto-built binaries produced from a CI system) is a
> chunk of extra work for the release managers.

This is actually the heart of the reason I asked the question.  CI tools are fairly good now.  If the CI tools could be used in such a way to make the building of binary artifacts less of a burden on the release managers, would there be interest in doing that, and in the process, releasing binary artifact installers for all security update releases.

My rationale for asking if its possible is... well.. security releases are important, and it's hard to ask Windows users to install Visual Studio and build python to use the most secure version of python that will run your python program.  Yes there are better ideal solutions (porting your code to the latest and greatest feature release version), but that’s not a zero burden option either.

If CI tools just aren't up to the task, then so be it, and this isn't something I would darken -ideas' door with.

> 2. The releases in question are essentially end of life, and we're
> only accepting security fixes.
> 3. Not even releasing sources means that people still using those
> releases will no longer have access to security fixes, so we'd be
> reducing the length of time we offer that level of support.
> 
> So extra binaries = more work for the release managers, no source
> release = less support for our users.
> 
> There's no reason we couldn't have a discussion on changing the
> policy, but any such discussion would probably need active support
> from the release managers if it were to stand any chance of going
> anywhere (as they are the people directly impacted by any such
> change).
> 
> Paul