Repository navigation
Drop py3.8 support tracker #14284
Description
Coming up soon "On Apr 14, 2023 drop support for Python 3.8 (initially released on Oct 14, 2019)" (https://numpy.org/neps/nep-0029-deprecation_policy.html).
This issue is to track things that should be updated when our minimum Python version is 3.9.
(Possibly relevant) New features in Python:
- union operators for dict (I think pyupgrade will fix most of these)
- relaxed decorator grammar
- string methods to remove prefixes and suffixes.
os.readlinkcan be replaced bypathlib.Path.readlink
Activity
[-]Drop py3.8 support?[/-][+]Drop py3.8 support tracker[/+]mhvk commentedon Jan 18, 2023
I think we can also drop numpy 1.20.
Also, I don't think we necessarily have to change any code -- after all, some of the things are just nice syntactic sugar -- it is more that we can now freely use them in new additions.
mhvk commentedon Jan 18, 2023
p.s. Numpy to be done in a different PR, so perhaps I should not have mentioned it here -- just a consequence of NEP 29 too...
pllim commentedon Jan 19, 2023
Is 5.3 too soon though? We might run into problems like #13255 where our users are stuck in older Python and unable to get a patch.
mhvk commentedon Jan 19, 2023
I think here we should simply follow our own procedure. At some point, if enough users really need to work with older python versions beyond what is possible with LTS, it is up to them to backport fixes, create wheels, etc.
p.s. I do wonder a bit about applying
pyupgradeautomatically, as that seems close to on purpose breaking code that used to work fine on older versions of python, which goes beyond just allowing new or refactored code to use new patterns. But then, there is an advantage to use the same patterns everywhere -- such as the f-strings.pllim commentedon Jan 20, 2023
While we do ask people to create PRs (which you could argue include direct backports), creating their own wheels/releases (outside of our canon distro) would go cause
astropyitself to have multiverse, which would be a maintenance nightmare. Unless I misunderstood what you are saying?dhomeier commentedon Jan 20, 2023
The critical point in that issue seems rather until when the Python version is supported, which would be ~October 2024 for 3.8. Would we still have a 5.x LTS at that time?
mhvk commentedon Jan 20, 2023
@pllim - I was just trying to say that beyond what we officially support, people are on their own. I don't see a reason to deviate from NEP 29, which includes no longer support python 3.8 for our next release.
@dhomeier - I think we support 5.0.x until Nov 2023, when we release 6.0 (if I got my counting right...)
dhomeier commentedon Jan 20, 2023
So at that point 5.3.x (or 5.4.x or whatever is the then-current feature release) will become the next LTS? Just trying to figure out how exactly the 2 years support time in https://github.com/astropy/astropy-APEs/blob/main/APE2.rst#release-scheduling-and-lts is to be understood.
pllim commentedon Jan 20, 2023
No, 6.0.x will be the new LTS when 6.0.0 is released. All old versions will no longer be supported.
dhomeier commentedon Jan 20, 2023
Meaning any release pre-6.0 will be dropped the instant 6.0.0 is out? How does this go along with
?
pllim commentedon Jan 21, 2023
At least that is my understanding... maybe others can confirm... @eteq , @astropy/astropy-project-release-team , et al.
astrofrog commentedon Jan 21, 2023
Once 6.0 is out it will be the only supported release. Prior to that we will have supported 5.0.x for two years, and after that we will support 6.0.x for two years.
dhomeier commentedon Jan 21, 2023
Ah, that's what the 4 * 6 months intervals add up to.
So, I happen to install, say then-current 5.3.2 this autumn and 6.0.0 comes out 4 weeks later, my installation will be supported for one month?
astrofrog commentedon Jan 21, 2023
Yes that's correct
mhvk commentedon Jan 21, 2023
Note that this is true also if you install 5.2.2 in March; once 5.3 is released in April, support for 5.2 stops.
hamogu commentedon Feb 24, 2023
But back to a comment higher up this chain: I agree with @mhvk to not automatically update code to new features for no reason; just use them when working on code and writing new code. That way we don't break working code just to break it; if someone is stuck on older version of Python, it might make their live easier to have astropy still be mostly compatible with 3.8 (e.g. maybe they only import one specific sub-package)?
pllim commentedon Feb 28, 2023
At the infrastructure tag-up on 2023-02-28, release managers had given a go to drop Python 3.8 for astropy v5.3. It is also agreed that we should keep introducing Python 3.8+ specific stuff to a minimum for now to ensure we can still backport to 5.0.x and 5.2.x without much pain.