[Python-Dev] PEP 466: Proposed policy change for handling network security enhancements

[Terry Reedy]

On 3/23/2014 9:00 AM, Skip Montanaro wrote:
> On Sat, Mar 22, 2014 at 11:31 PM, Terry Reedy <tjreedy at udel.edu> wrote:
>> The download page for the final 2.7.z maintenance release could say
>> something like "We recommend that you move to the most recent Python 3
>> version if at all possible. If you cannot do that and you want to use Python
>> to run a server on the public internet, we urge you to instead use the
>> latest version of ServerPython 2.7.1s. This series is based on Python 2.7.z
>> but has been and will continue to be enhanced with security features
>> backported from Python 3."
>
> I'm unclear how this would be better than just biting the bullet and
> making a 2.8 release.

The first step is to 'bite the bullet' and admit that the proposal is 
for a fork of 2.7. (Martin use that word today and pointed out the 
analogy with Stackless Python.) I decided not to suggest '2.8' because 
a) we said there would be no 2.8 (though that could be reversed); b) 
once we say '2.8', there would be a mountain of proposals to change this 
and that; c) people will expect the change from 2.7 to 2.8 to be 
something like previous deltas, but it will not be; d) the security fork 
might have a change that would normally require a deprecation period, 
but there might not be; and e) once a 2.8 were released, it too would be 
closed to enhancements, so that 2.9, 2.10, 2.11.. would eventually be 
needed. I mentioned this as one possible solution, but one I do not 
like. In summary, "2.8 is to 2.7 as 2.7 is to 2.6, etcetera" would not 
be true, so lets not pretend or mislead people that is would be.

The fork series, not being a regular CPython series, would not be 
subject to the regular CPython rule of needing a new minor version 
number for each set of enhancements and spacing the sets 18 to 24 months 
apart.

 > On the one hand, the 2.7.x number suggests
> (based on the existing release protocol) that it should be a drop-in
> replacement for earlier 2.7 micro releases.

No CPython x.y.z has a two-digit number for z. I know that this is a 
subtle hint, which is why I also propose a new name. I do not think that 
anyone expects Stackless Python 2.7 to be an exact drop-in replacement 
for any 2.7.z, although it is for code that is not affected by its 
specialized alterations.

 > On the other hand, calling
> it something like "ServerPython" implies that it's not necessary for
> network client applications, when, if I read the PEP correctly, it
> most certainly would be.

Consider 'ServerPython' a placeholder for a better name. In my 
penultimate sentence "There are still details to be filled in or 
altered," I was specifically thinking of this.

> If you create a 2.8 release which is restricted to just the topic
> areas of the PEP (that is, no other stuff backported from 3.x, no
> requirement to add other non-security bug fixes, etc), the incremented
> minor version number tells people that a bit of extra care is required
> to upgrade. The lack of change in the code base outside the security
> apparatus should make update pretty trivial for most every
> non-networked application. If the PEP or something like it is
> approved, the work is still going to have to be done, no matter what
> you call it. Why not be transparent about it?

We agree on being transparent, even if we have different ideas on 
exactly what needs to be made clear.

-- 
Terry Jan Reedy