#1 deprecation schedule
Opened 3 years ago by tkopecek. Modified 3 years ago
tkopecek/koji-planning deprecation  into  master

@@ -0,0 +1,27 @@ 

+ Deprecation Schedule

+ ====================

+ 

+ +------------------------+------+------+------+------+---------+-------+

+ | Python 2 packaging     | lib  | cli  | hub  | web  | builder | utils |

+ +========================+======+======+======+======+=========+=======+

+ | Python 2 packaging     | 1.25 | 1.25 | 1.22 | 1.22 | 1.25    | 1.23  |

+ +------------------------+------+------+------+------+---------+-------+

+ | Python 2 compatibility | 1.30 | 1.30 | 1.22 | 1.22 | 1.30    | 1.23  |

+ +------------------------+------+------+------+------+---------+-------+

+ | --ca option            | 1.24 | 1.24 | 1.24 | 1.24 | 1.24    | 1.24  |

+ +------------------------+------+------+------+------+---------+-------+

+ | tagHistory             | 1.23 | 1.23 |      |      |         |       |

+ +------------------------+------+------+------+------+---------+-------+

+ | host.getTask           | 1.23 |      |      |      |         |       |

+ +------------------------+------+------+------+------+---------+-------+

+ | krb_login              | 1.22 | 1.22 | 1.22 | 1.22 | 1.22    | 1.22  |

+ +------------------------+------+------+------+------+---------+-------+

+ 

+ Reasoning behind python 2 support is as follows. We expect, that there are still

+ running builder on CentOS/RHEL6. EOL of RHEL6 is planned on 2020-11-30. So, we

+ are obliged to provide RHEL6 support at least until that (somewhere around 1.25

+ release). Then we want to end the packaging and maintain python2 code

+ compatibility for a next year (until 1.30) in case problems will arise.

+ 

+ We also want to be sure, that everything works with python 3 on CentOS/RHEL7 in

+ that time.

no initial comment
Metadata