[Python-Dev] Fixing 2.7.x
R. David Murray
rdmurray at bitdance.com
Mon Oct 6 21:45:52 CEST 2014
On Mon, 06 Oct 2014 21:18:23 +0200, Christian Tismer <tismer at stackless.com> wrote:
> On 06.10.14 20:55, Zachary Ware wrote:
> > On Mon, Oct 6, 2014 at 12:24 PM, Ned Deily <nad at acm.org> wrote:
> >> 3. security: "fixing issues exploitable by attackers such as crashes,
> >> privilege escalation and, optionally, other issues such as denial of
> >> service attacks. Any other changes are not considered a security risk
> >> and thus not backported to a security branch."
> >> = 3.2.x and 3.3.x
> > 3.1 is still in this category, is it not? According to PEP 375, it's
> > a few months past due for its last release.
> > http://legacy.python.org/dev/peps/pep-0375/#maintenance-releases
> I don't think that the rules should be implicitly considered
> compatible between the 2.X and 3.X series.
> Python 2.X has a history that extends to X==6, X==5 and
> even X==4, as a really conservative POV with an extent over more
> than 10 years.
> I believe, such a thing does not exist for the Python 3.X series
> at all. My impression is that no 3.X user ever would want to stick
> with any older version.
> Is that true, or am I totally wrong?
I don't think you are *totally* wrong, but I don't think you are really
right, either. I myself have at least one system (I didn't check them
all) running 3.2 that I have intentionally only done security fixes on
rather than upgrade python3. It's mostly laziness (given that my distro
provides the security updates), since I don't think there would be any
compatibility problems with the few python3 programs running on it, but
I'm likely not the only one.
So yes, the same rules should apply to python3 as apply to python2,
especially since more distros are about to start shipping python3 as
the system python (Arch has been since 2011).
3.1, however, is most likely a dead issue.
More information about the Python-Dev