1 |
Hello, fellow developers. |
2 |
|
3 |
On behalf of Python team, I would like to announce that we're |
4 |
officially discontinuing support for Python 2.5, Python 3.1 |
5 |
and PyPy 1.9. |
6 |
|
7 |
If you still actively use any of those implementations, please migrate |
8 |
to a newer version. We have ensured already that no in-tree package |
9 |
doesn't support one of the newer implementations. |
10 |
|
11 |
I have just committed a package.mask and use.mask entries for them |
12 |
and unless anybody objects strongly, we will remove them in 30 days |
13 |
from now. After the removal, we will disable the support for them |
14 |
in the eclasses and proceed with semi-automated update of PYTHON_COMPAT. |
15 |
|
16 |
Any questions shall arise, please do not hesitate to reply |
17 |
to gentoo-dev@ or discuss in bug #480070 [1] that is dedicated |
18 |
to the issue. |
19 |
|
20 |
[1]:https://bugs.gentoo.org/show_bug.cgi?id=480070 |
21 |
|
22 |
|
23 |
A short rationale: |
24 |
|
25 |
The Python team is finding it difficult to maintain the old Python |
26 |
implementations. Since we tend to run the newest versions, the old ones |
27 |
don't receive proper testing and we can either rely on the tests (which |
28 |
not all packages have) or simple manual testing that consumes a lot |
29 |
of time. |
30 |
|
31 |
Furthermore, upstreams tend to test their packages with newer versions, |
32 |
and therefore the test failures are much more common with the old |
33 |
versions. Addressing those usually involves much more effort than |
34 |
benefit. |
35 |
|
36 |
Python 2.5 dates back to 2006. It had last security fix mid-2011 |
37 |
as v2.5.6 but the newest in the tree is v2.5.4 which proves that it's |
38 |
unmaintained. The following version -- 2.6 -- has much better support |
39 |
for Python3 compatibility and therefore projects aiming at supporting |
40 |
both Python2 & Python3 are often dropping support for 2.5. |
41 |
|
42 |
This became especially visible when dev-python/pil has been introduced |
43 |
to the tree, as a replacement for dev-python/imaging. Since PIL |
44 |
supports 2.6 up to 3.3 and imaging 2.5 up to 2.7, it became no longer |
45 |
possible to easily have all the listed implementations enabled. That's |
46 |
why most of developers simply disabled 2.5 and it stopped receiving any |
47 |
testing. |
48 |
|
49 |
Python 3.1 dates back to 2009. It's the second Python3 'slot', that has |
50 |
serious improvements over 3.0. However, it's still not as good as 3.2 |
51 |
and therefore most of effort on switching to Python3 focuses on 3.2+. |
52 |
I've been told that this version has some API incompatibilities that |
53 |
make it hard to write portable Py2+3 code that works in 3.1, |
54 |
and that's why a number upstreams doesn't support it. I have no strong |
55 |
proof of that. |
56 |
|
57 |
Additionally, a first alpha of Python 3.4 has been released a few days |
58 |
ago. Considering that, we will be getting a new Python 3 version to |
59 |
maintain soon enough and we should make some space for it. |
60 |
|
61 |
PyPy support is still mostly experimental and buggy. All PyPy versions |
62 |
so far reuse the standard library from Python 2.7, therefore there is |
63 |
no specific reason to keep multiple slots. Moreover, PyPy 2.1 was just |
64 |
released and we'll be adding it soon; and PyPy3 2.1 (Python3 variant) |
65 |
will be released soon. |
66 |
|
67 |
-- |
68 |
Best regards, |
69 |
Michał Górny |