Closed ejeschke closed 5 months ago
Skip #805 as it is likely to never be merged in favor of something implementing #1056
@pllim, I'm thinking for v5.0 we should update the requirements for python
(3.7 => 3.8), astropy
(3.2 => 4.2) and numpy
(1.14 => 1.22). What do you think?
astropy 4.2 is pretty old. Is there a reason why you cannot bump it to 5.x ?
When is the end of support for 4.2? I mostly don't want to pull the rug out from anyone that is stuck in an older set of packages. This is true for some observatories, especially. Although our main observing software is using astropy 5.x, some of the instruments and their pipelines are stuck in older versions.
astropy 4.x reached EOL when astropy 5.0 came out, so that was back in Jan 27, 2022. And we will stop supporting 5.x when we release astropy 6.0 at the end of 2023 (after about 2 years since release). As per APE 21, starting in 6.0, we no longer do LTS, so that means 6.0 is not guaranteed to receive bugfix for the next 2 years (it might but we just don't make that promise anymore). Hope this clarifies the matter.
I followed that "dropping LTS" discussion with interest. I suppose we can bump up the requirement to 5.0.
If you bump to astropy 5.x, Python 3.8 and numpy 1.22 sound reasonable. I just cannot say for astropy 4.x because we have not been testing it for over a year.
Following bump to python 3.8, I think we can change this module in the same update.
As author of the these PRs, I request not to merge #761 (needs more testing with current version) and #1015 (not full ready, IMO) for release 5.0
SInce there doesn't seem much interest in #813, I suggest to not merge that for release 5.0 as well.
We played with the idea of plugging in reproject
into Jdaviz too but abandoned it because it is too resource intensive.
Kicking the can on #698, #823 and #940 down the road for possible resolution in a future release.
Released! (or should I say "Unleashed" :smile_cat: )
ToDo list: