Drop Python 2 support #3873

Closed
opened 2022-02-14 13:35:23 +00:00 by itamarst · 5 comments
itamarst commented 2022-02-14 13:35:23 +00:00
Owner

Accidental Python 2 incompatibility is wasting my time, and inability to use Python 3 features (even just in new modules) is somewhat frustrating.

Python 3 support has been out for 4 months, and there have been three releases with Python 2+3 support already. If Python 2 fixes are needed they can be done off a branch taken from the latest one of those.

Proposed plan for this particular iteration:

  • Remove all Python 2 builders.
  • Only allow Python 3 features in new modules (i.e. HTTP storage) for now, so that backports of critical bug fixes and security updates can happen for a few more months.
Accidental Python 2 incompatibility is wasting my time, and inability to use Python 3 features (even just in new modules) is somewhat frustrating. Python 3 support has been out for 4 months, and there have been three releases with Python 2+3 support already. If Python 2 fixes are needed they can be done off a branch taken from the latest one of those. Proposed plan for this particular iteration: * Remove all Python 2 builders. * Only allow Python 3 features in new modules (i.e. HTTP storage) for now, so that backports of critical bug fixes and security updates can happen for a few more months.
tahoe-lafs added the
unknown
normal
enhancement
n/a
labels 2022-02-14 13:35:23 +00:00
tahoe-lafs added this to the Support Python 3 milestone 2022-02-14 13:35:23 +00:00
exarkun commented 2022-02-14 13:37:26 +00:00
Author
Owner

Do the Python 3 builders cover all of the same platforms and configurations the Python 2 builders cover? That is, do we lose CI coverage for anything other than Python 2 when we drop all of the current Python 2 builders?

Do the Python 3 builders cover all of the same platforms and configurations the Python 2 builders cover? That is, do we lose CI coverage for anything other than Python 2 when we drop all of the current Python 2 builders?
exarkun commented 2022-02-14 13:39:16 +00:00
Author
Owner

For the second bullet point, I don't know if it's worth it. I'm not sure we'll actually be able to produce a bugfix-only release from an old release branch. We have not done that in recent history, there is no documented process, and without CI it seems particularly fraught.

I think we should make sure we get full CI coverage from Python 3 CI jobs and then just drop Python 2 completely, including from the development process.

For the second bullet point, I don't know if it's worth it. I'm not sure we'll actually be able to produce a bugfix-only release from an old release branch. We have not done that in recent history, there is no documented process, and without CI it seems particularly fraught. I think we should make sure we get full CI coverage from Python 3 CI jobs and then just drop Python 2 completely, including from the development process.
itamarst commented 2022-02-14 13:48:01 +00:00
Author
Owner

Some of current CI builders are for obsolete platforms. Specifically:

  • Debian 9. Debian 10 came out in mid-2019, Debian 11 came out in 2011. Debian 9 doesn't have sufficiently new Python 3. We should drop it and add Debian 10 and Debian 11 instead.
  • CentOS 8. CentOS 8 is no longer a supported operating system (though RHEL 8 is supported, and will be for many years), but there are equivalents like Oracle Linux we could switch to as equivalent drop-in for RHEL 8. RHEL 8 and clones have Python 3.8 and 3.9.
  • Fedora 28 and 29 haven't been supported platform since late 2019. Should switch to newer Fedora.
  • Ubuntu 16.04 technically has support, but I'm guessing it doesn't provide modern Python 3, and there will be three newer LTSes (18.04, 20.04, 22.04) in two months, so I say just drop it.
  • Ubuntu 18.04 has Python 3.7 so it's fine for now.
Some of current CI builders are for obsolete platforms. Specifically: * Debian 9. Debian 10 came out in mid-2019, Debian 11 came out in 2011. Debian 9 doesn't have sufficiently new Python 3. We should drop it and add Debian 10 and Debian 11 instead. * CentOS 8. CentOS 8 is no longer a supported operating system (though RHEL 8 is supported, and will be for many years), but there are equivalents like Oracle Linux we could switch to as equivalent drop-in for RHEL 8. RHEL 8 and clones have Python 3.8 and 3.9. * Fedora 28 and 29 haven't been supported platform since late 2019. Should switch to newer Fedora. * Ubuntu 16.04 technically has support, but I'm guessing it doesn't provide modern Python 3, and there will be three newer LTSes (18.04, 20.04, 22.04) in two months, so I say just drop it. * Ubuntu 18.04 has Python 3.7 so it's fine for now.
itamarst commented 2022-02-14 13:49:26 +00:00
Author
Owner
  • Some of the specialized builders (locale?) are probably on obsolete platforms and can be updated (or maybe Python 3 makes them unnecessary? I keep forgetting how that awfulness works).
* Some of the specialized builders (locale?) are probably on obsolete platforms and can be updated (or maybe Python 3 makes them unnecessary? I keep forgetting how that awfulness works).
exarkun commented 2022-02-14 13:51:57 +00:00
Author
Owner

OS updates sound good.

We noted the need to do some of this quite a while ago but no one was interested in doing it:

https://tahoe-lafs.org/trac/tahoe-lafs/ticket/3327

Maybe we should drop Fedora on CI if there is no one interested in doing the maintenance? (We could try harder to find someone to do the maintenance first, though).

OS updates sound good. We noted the need to do some of this quite a while ago but no one was interested in doing it: <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/3327> Maybe we should drop Fedora on CI if there is no one interested in doing the maintenance? (We could try harder to find someone to do the maintenance first, though).
tahoe-lafs added the
fixed
label 2022-02-22 18:07:12 +00:00
itamarst closed this issue 2022-02-22 18:07:12 +00:00
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: tahoe-lafs/trac-2024-07-25#3873
No description provided.