1 |
On Mon, 01 Jun 2020 22:27:19 +0200 |
2 |
Michał Górny <mgorny@g.o> wrote: |
3 |
|
4 |
> Hi, everyone. |
5 |
> |
6 |
> I'd like to be more proactive in avoiding the mess like Python 3.6->3.7 |
7 |
> switch were. For this reason, I think it would be better to set |
8 |
> and publish some early deadlines. Even if we aren't going to strictly |
9 |
> keep to them, it would help people realize how much time there is left |
10 |
> to finish the preparations. |
11 |
> |
12 |
> |
13 |
> Python 3.6→3.7 migration |
14 |
> ======================== |
15 |
> We've already switched the profiles but there are still some unmigrated |
16 |
> packages. We will continue either migrating them or last riting if |
17 |
> migration seems unlikely to happen. Nevertheless, it is wortwhile to |
18 |
> set some final deadlines. My proposal is: |
19 |
> |
20 |
> |
21 |
> 2020-08-01 Python 3.7 migration deadline |
22 |
> |
23 |
> After this date, we lastrite all remaining packages that haven't been |
24 |
> ported. This gives people roughly two months, with a ping one month |
25 |
> from now. |
26 |
> |
27 |
> 2020-09-15 Python 3.6 target removal |
28 |
> |
29 |
> As usual, the interpreter will be kept a bit longer, then moved to |
30 |
> ::python. This accounts for some extra time if people decide to |
31 |
> recover last rited packages last minute. |
32 |
|
33 |
Given that 2020-08-15 is still well over a year before the upstream EOL, |
34 |
this might be a little premature. How about we the deprecation dates back |
35 |
by 4 months? We can still have a similar schedule, just a little later. That |
36 |
way we are deprecating 3.6 less than a year before the EOL upstream. |
37 |
|
38 |
We can keep the 2.7 removal as-is. |
39 |
|
40 |
> |
41 |
> Python 3.7→3.8 migration |
42 |
> ======================== |
43 |
> The interpreter is stable but there's still lot of migration work to be |
44 |
> done. Good news is that because of the delay with 3.7, many packages |
45 |
> are getting 3.7+3.8 or even 3.7+3.8+3.9 simultaneously, so there will be |
46 |
> less work in the future. |
47 |
> |
48 |
> |
49 |
> 2020-07-01 Python 3.8 target stable-unmasking goal |
50 |
> |
51 |
> This is not really a deadline but I'd like to aim for resolving |
52 |
> depgraph issues and stabilizing everything needed to unmask python3_7 |
53 |
> target on stable. Initial set of stablereqs was filed already, |
54 |
> and we'll be unmasking the target as soon as the depgraph is clean. |
55 |
> |
56 |
> 2020-09-01 Python 3.8 migration warning |
57 |
> |
58 |
> At this point we tell people it's about time to start actively |
59 |
> updating their packages. |
60 |
|
61 |
Under my suggested timeline, I would say we do this 2020-12-01. |
62 |
|
63 |
> 2020-12-01 Python 3.8 migration deadline |
64 |
> |
65 |
> We lastrite all the unmigrated packages. |
66 |
|
67 |
This could be pushed back to 2020-05-01 to not be too close to the 3.6 |
68 |
removal. I personally do not have any strong feelings either way about |
69 |
3.7, so I would be fine removing 3.6 and 3.7 at the same time if that |
70 |
is easier. |
71 |
|
72 |
> 2021-01-15 Python 3.7 target removal |
73 |
> |
74 |
> As above. |
75 |
> |
76 |
> |
77 |
> Python 2.7 removal |
78 |
> ================== |
79 |
> I would like to continue removing py2.7 from packages where possible, |
80 |
> and slowly lastriting where clearly impossible. However, |
81 |
> for the remaining packages I'd like to set a hard deadline. |
82 |
> |
83 |
> |
84 |
> 2021-01-01 Final Python 2.7 deadline |
85 |
> |
86 |
> That's one year after upstream's EOL. At this point, we last rite |
87 |
> all the remaining py2.7 packages. |
88 |
> |
89 |
> 2021-02-15 Python 2.7 target removal |
90 |
> |
91 |
> All packages relying on the target are removed. The interpreter |
92 |
> stays for as long as we need it. |
93 |
> |
94 |
> |
95 |
> General goal |
96 |
> ============ |
97 |
> As a general goal, I'd like to set timelines like this once we decide |
98 |
> that the next interpreter goes stable. The exact lengths are highly |
99 |
> dependent on properties of the next target. For example, I suspect |
100 |
> Python 3.9 will be easier for us; so far my testing has shown issues |
101 |
> that are rather easy to solve. |
102 |
> |
103 |
|
104 |
Here is an attempt at updating version of ASCII art, from what |
105 |
I can tell, the 'w' at the 3.7->3.8 warning probably belonged |
106 |
in the 3.7 column, I moved it. As I said above, I am personally |
107 |
fine if we make 3.6 and 3.7 removals close together (even at |
108 |
the same time). |
109 |
|
110 |
Combined timeline |
111 |
================= |
112 |
From the above dates: |
113 |
|
114 |
2.7 3.6 3.7 3.8 |
115 |
2020-07-01 | | | u py3.8 target unmasked |
116 |
| | | | |
117 |
| | | | |
118 |
| | | | |
119 |
| | | | |
120 |
| | | | |
121 |
| | | | |
122 |
2020-12-01 | | w | py3.7→3.8 migr. warning |
123 |
| | | | |
124 |
| | | | |
125 |
2021-01-01 m | | | py2.7 pkg last rites |
126 |
| | | | |
127 |
| | | | |
128 |
2021-02-01 | m | | py3.6 pkg last rites |
129 |
| | | | |
130 |
2021-02-15 x | | | py2.7 pkg removal |
131 |
2021-03-15 x | | py3.6 pkg removal |
132 |
| | |
133 |
| | |
134 |
| | |
135 |
2021-05-01 m | py3.7 pkg last rites |
136 |
| | |
137 |
| | |
138 |
2021-06-15 x | py3.7 pkg removal |
139 |
| |
140 |
v |