On 3/23/2014 9:00 AM, Skip Montanaro wrote:
On Sat, Mar 22, 2014 at 11:31 PM, Terry Reedy <tjre...@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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
