Sticking to SPEC 0 and dropping numpy < 2.0 for astropy 8.0

[Marten van Kerkwijk]

Hi All,

Our minimum requirements nominally follow SPEC 0 (https://scientific-python.org/specs/spec-0000/), which means that for 8.0 (to be released in May 2026), our minimum numpy version should become 2.0. I would like to check that there is agreement to actually raise the minimum version accordingly.

I ask in part since dropping 1.x would have been possible already for 7.2, but there was pushback arguing that users might be stuck on 1.x.

More generally, though, I would like to check whether there is agreement that these kinds of updates to the minimum requirements can be automatic in the future. Personally, I thought automatic changes were one of the main advantages of SPEC 0 -- as it makes clear what to expect. Indeed, SPEC 0 states right on top that:

> This SPEC recommends that all projects across the Scientific Python ecosystem adopt a common time-based policy for dropping dependencies.

Certainly, my personal logic is that if people are stuck on numpy 1.x, there is nothing wrong with them being stuck to astropy 7.x as well, and hence we should simply follow SPEC 0 (with it being irrelevant whether or not it (appears to) be much work to keep work-arounds for older versions in place).

Anyway, thoughts welcome!

All the best,

Marten

[Clément Robert]

Hi Marten, thanks for opening this discussion

>  but there was pushback arguing that users might be stuck on 1.x.

I can tell you now: there's going to be pushback against dropping support for numpy 1.x even in May 2026, because the argument that some users are not able to upgrade yet will still hold by then.

It should be self-evident by now that I'm not a SPEC 0 absolutist; I recognize the value of a simple and shared policy, but I do want to take a step back before we can consider automatic upgrades.

Who benefits from removing compatibility code ? the argument seems to be that it gets in the way of developers, so I assume that they are the presumed beneficiaries.

And who's paying for any drawback of such aggressive clean ups ? Users, and the ones operating in already precarious conditions, especially so.

I don't think this is the kind of trade-off that should be taken lightly, let alone, automated. Granted, compatibility code is temporary anyway, but it costs real man hours to build, provides actual value to end users, and is (as far as I know) free to maintain, so why not just let it shed itself off ?

To some extent, I feel I may be missing an argument entirely, because I do not understand why there would be a consensus for removing compatibility code that represents close to 0 maintenance burden *before* it naturally decays off into obsolescence.

> Certainly, my personal logic is that if people are stuck on numpy 1.x, there is nothing wrong with them being stuck to astropy 7.x as well

what if numpy 2.x is unavailable on their linux distro, but astropy 7.x has some bugs that are critical to them ? What if a specific project of them is stuck on numpy 1.x because of another dependency that has much less resources than we do and wasn't able to catch up yet ?

We are not talking about software that is hard or costly to maintain here: our compatibility layer for numpy 1 is essentially paying for itself right now. Besides the slight discomfort *we* developers and maintainers may feel when reading code with a history, what's solved by these clean ups ?

Clément

[Aldcroft, Tom]

> my personal logic is that if people are stuck on numpy 1.x, there is nothing wrong with them being stuck to astropy 7.x as well,

Chandra ops runs astropy on some non-networked machines and not updating regularly means the leap-second files get out of date and warnings start appearing. We have run into this in practice and it essentially forced updating astropy to fix (in a proper way). With no LTS this effectively means updating to the latest feature branch.

We run ops using a tightly configured suite of around 50 in-house packages and hundreds of core-package dependencies. We generally update the core packages annually. This year we are planning to *try* updating to numpy 2.x, but success is not assured. First, do all our dependencies support numpy 2.x? Second, how many tests break and do we have time to fix them?

I suspect that Chandra operations is not the only organization in this boat.

The other question is what other major projects are doing. Scipy, pandas, scikit-learn, and matplotlib all support numpy 1.26 in current dev. Astropy should not be leading the community in dropping support for numpy 1.26 unless there is a good reason. This does imply not following SPEC 0 for this particular corner case, but we are not alone in seeing this one as special.

- Tom

--
You received this message because you are subscribed to the Google Groups "astropy-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to astropy-dev...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/astropy-dev/cdf57ccc-a2e2-428d-98bf-3b2cc86cef27n%40googlegroups.com.

[Marten van Kerkwijk]

Hi Clement,

I think there is an opportunity cost at least for development work, in
that if we do not upgrade in a timely manner, we cannot use new
features. This is particularly relevant for numpy 2.0, since it made
large changes in, e.g., how dtype are organized.

For instance (a concrete example that is part of my cycle 5 funding
proposal and that I hope to have ready for 8.0): It is now possible to
have a dtype that will do scaling as part of a ufunc call, so that for
np.sin(large_q_in_degrees) it is no longer needed to make a new array of
large_a in radians, and then create another new array with the sin of
it, but the multiplication can be done as part of the sin ufunc, in the
chuncks used by the iterator.

By sticking to numpy < 2, we are holding up such changes. Now my
particular example is large enough that it may suffice to drop numpy 1.x
on its own, but my argument is more that by *knowing* when a minimum
version will be raised, it allows anyone to start using new features in
our dependencies closer to when they are introduced. It also avoids
having to have a discussion about whether or not a given new feature is
"worth it" for the "pain" given to users stuck to older versions.

In this sense, it is similar to python versions. E.g., we could have
decided not to use f-strings and then we'd perhaps still be able to
support early versions of python 3... I'm really happy that those
updates are just automatic; I'd like that to be true for all of our
required dependencies (optional ones can be more flexible).

But in the end it is about weights: I find the examples of people
"stuck" unconvincing. The likelihood that someone has a dependency that
cannot deal with numpy 2.0 *and* absolutely requires a newer version of
astropy (and cannot work around the older astropy's problem) seems very
small indeed. Everything else would seem solvable by creating a new
virtual environment and doing pip/conda install astropy.

All the best,

Marten

[Marten van Kerkwijk]

Hi Tom,

If leap second files are the problem, we should make sure those are part
of astropy-iers-data (I actually thought they were!?). Certainly, I
think it is a bug if you need to upgrade astropy to get leap seconds up
to date. Please do raise an issue!

For reference, SPEC 0 suggests dropping numpy 1.x about now, so if other
packages have not yet jumped to it, that is not surprising. I was not
trying to argue after-the-fact that it was a mistake not to drop numpy
1.x in 7.2; I'm only arguing that we should feel free to do so for our
next major version, 8.0, and that there is an advantage in following
SPEC 0 that we do not have to have these discussions.

All the best,

Marten

p.s. Your example does argue it may have been a mistake to move away
from having a LTS version.

[Clément Robert]

> we cannot use new features

This is certainly true for syntactic features of Python itself as a language, but I'm not convinced yet that this is true here; there are usually ways to take advantage of new (non syntactic) features very soon without making them hard requirements. For instance, h5py currently has features that *require* building with numpy 2, and are only available at runtime if a sufficiently recent version of numpy is detected, but we still very much support building *and* running against numpy 1 (you just don't get to enjoy these features if you're stuck in this position). To me, this is what being a core library means. I understand that the feature you want to bring to astropy may require additional work to be made *conditionally* available, but I'm not convinced yet it isn't possible; maybe this doesn't need to be a major concern to you specifically, and I'd be happy to help with the backward-compatibility part if I can.

> In this sense, it is similar to python versions. E.g., we could have

decided not to use f-strings and then we'd perhaps still be able to
support early versions of python 3...

I feel like this isn't an honest comparison; I'm not advocating to maintain support for 17 year old Pythons here, I'm merely asking that we *try* to preserve support for our main dependency longer than 2 years. There should be a middle point we can meet at. Side note: I indeed think we should be trying to preserve backward compat for Python versions for a bit longer than what SPEC 0 *allows* for, but I don't see much point in supporting versions that are EOL (currently this would be <=3.9).

> and that there is an advantage in following SPEC 0 that we do not have to have these discussions.

I'm going to quote myself here if you'll allow me:
I don't think it's a valid argument to shut all further discussions on the ground that a previous agreement was supposed to make them unneeded. The current approach creates actual problems, we should at least be able to discuss amending it.

Clément

[Stuart Mumford]

I'm not going to say too much here, but I think the reasons that SPEC 0
was written and agreed on are important to bear in mind. It's a way of
projects banding together to collectively say we don't have the
resources to continue to support old versions of things, if you are
running our stuff then you need to update, or manage your own
environment without expecting "us" (all largely volunteer packages) to
do it for you.

> but I'm not convinced yet it isn't possible; maybe this doesn't need
> to be a major concern to you specifically, and I'd be happy to help
> with the backward-compatibility part if I can.

This to my mind is exactly the kind of cost associated with supporting
old versions of things. If you spend X amount of time working on numpy
1.x backwards compatibility what other excellent work are you not
getting done which moves the whole ecosystem forwards rather than
standing still?

fwiw, SunPy has decided to keep numpy 1.26 support longer than SPEC 0
recommends because it is currently costing us literally nothing. If that
changes at some point then it'll be gone.

Stuart

[Marten van Kerkwijk]

Hi All,

As Stuart points out, there is a cost to keeping old versions going. Indeed, these include having discussions like these for every release -- collectively, here and in the issue about optional dependencies, we probably spent the equivalent of 4--8 man hours, or of order $1000. If we just follow SPEC 0, as we decided in APE 18 (https://github.com/astropy/astropy-APEs/blob/main/APE18.rst), none of that would be necessary.

And the costs of keeping numpy 1.x support are not negligible, to me at least. To give a sense, `git grep NUMPY_LT_2_0 | wc` gives 146 hits (versus 4 for NUMPY_LT_1_26, about 20 each for other 2.x) so it is not a minimal amount of work-around code. Though more troubling to me remains that supporting older versions prevents use of new features. As I mentioned, I can use numpy 2.x features to make Quantity substantially faster.

Anyway, perhaps a compromise is possible: how about we move to a state where we keep the minimum versions fixed not just for bugfix releases but also minor ones. But for major releases, we should just stick to SPEC 0. This would also mean that if people really wanted longer support, *they* could take on responsibility for backporting possible fixes, effectively creating a kind of LTS version (but one where those interested are also responsible for it).

 

All the best,

Marten

On Wed, Nov 19, 2025 at 3:44 AM Clément Robert <clement....@gmail.com> wrote:

[Thomas Robitaille]

Hi all,

Just a request that we should avoid terms such as 'man hours' in these and other discussions - 'person hours' or simply 'hours' should be sufficient.

Cheers,

Tom

To view this discussion visit https://groups.google.com/d/msgid/astropy-dev/CAJNV%2B9uVRNCVj%3DYRze9cneoKpxbs-oHxp7pq%2ByZV8XEf6TiswA%40mail.gmail.com.

[Marten van Kerkwijk]

Hi All,

To get a proper sense of what would change, and to ensure that any downstream have enough time to adjust, I made a PR to drop support for numpy 1.x (for 8.0, obviously).

Overall, 65 files changed, about 500 lines changed and about 600 lines deleted. It is substantially more than I thought based on my grep of NUMPY_LT_2_0 because we no longer have to worry about different meanings of the `copy` argument -- COPY_IF_NEEDED can now always be `None`.

It took me about 1.5 hours to make the changes... (and I wouldn't be surprised if I made a mistake, though tests pass locally).

All the best,

Marten

To view this discussion visit https://groups.google.com/d/msgid/astropy-dev/CAGMHX_0xQA%3DWV_KTh0NWrz1TZ0bx2BawhbA093KogoCi%2B8EVPQ%40mail.gmail.com.

[Aldcroft, Tom]

There is nothing like actually doing the PR to make a point, thanks Marten! :-) Having seen #18986 in its full glory, that does look nice. Having stated my reservations previously, I'm now at least +0.5 on requiring numpy 2.x for astropy 8.0.

- Tom

To view this discussion visit https://groups.google.com/d/msgid/astropy-dev/CAJNV%2B9uzjusLjbT9bJGTWjHepXSz3LhoYhuAy9-%2BdJiNYcnn7A%40mail.gmail.com.

[Thomas Robitaille]

Out of curiosity, in practice what kind of users do we expect will be able to upgrade to astropy 8.0 but not be able to upgrade to numpy 2.0? (Just to make sure I understand the motivation for remaining compatible with 1.x)

Cheers,

Tom

To view this discussion visit https://groups.google.com/d/msgid/astropy-dev/CAMtEP6y-xv1JBjm7nd0%2Bf6aiectpPydZtCJQmbKyyXpHTu0vCw%40mail.gmail.com.

[Aldcroft, Tom]

On Tue, Nov 25, 2025 at 2:02 AM Thomas Robitaille <thomas.r...@gmail.com> wrote:

Out of curiosity, in practice what kind of users do we expect will be able to upgrade to astropy 8.0 but not be able to upgrade to numpy 2.0? (Just to make sure I understand the motivation for remaining compatible with 1.x)

See my email (3rd in this thread) for an example. It is not clear right now if we will have a problem upgrading to numpy 2.x for Chandra operations, and the only way to know is to try. If one of our many dependencies does not support numpy 2.x then we would be blocked.

- Tom

 

To view this discussion visit https://groups.google.com/d/msgid/astropy-dev/CAGMHX_0AB6spH04YQS8ZVHVmb24sm49uKLWBYyQu%3D-VBC4H43g%40mail.gmail.com.

[hamogu]

I support going to numpy > 2.0 for the 8.0 release because I agree that there is a better use of our time than maintaining compatibility to old versions, I agree that we are loosing out on new features, and I agree that there is a better use of our time than having this discussion.

If some user really can't upgrade numpy, they will have to stick with an older version of astropy as well. If they can't upgrade numpy, they are not working in an environment with cutting-edge packages, and they won't be using the new features of the new astropy versions. If one specific thing turns out to be a problem for e.g. Chandra operations, they (or we) can always look to make a backport of that one specific thing (e.g. the datafile of leap seconds). Let's cross that bridge if that actually turns out to be a problem, and not preemptively spend our time discussing (or coding for) situations that may never arise.

(As an aside, I've recently been in a discussion group with a NASA appointed committee on the future of software in high-energy astrophysics, and several attendees voiced that "we shouldn't rely on astropy, because they constantly break backwards-compatibility", so there seems to be a wide-spread perception that our code and our requirements are not stable enough. Still, I think the costs of maintaining compatibility with numpy < 2.0 outweighs the benefits for astropy.)

Moritz

[Marten van Kerkwijk]

Hi Tom,

> See my email (3rd in this thread) for an example. It is not clear right now if we will have a problem upgrading to numpy 2.x for Chandra
> operations, and the only way to know is to try. If one of our many dependencies does not support numpy 2.x then we would be blocked.

Is there any hope to find out from the previous upgrade what the problem
actually was? As I answered earlier, I thought we had basically fixed
all leap-second related problems, and if that's not the case, I'd dearly
like to know!

For reference, we've had a long discussion with the LST people for
work-arounds for using older IERS tables, which ended up giving a nice
work-around for them that did not involve loosening dependencies on our
side.

Note that to me what this shows, if anything, is that we dropped the
idea of having LTS too soon. You almost certainly don't need new
features of astropy 8.0, just *maybe* need the bug fixes and correct
IERS/leap-second data.

All the best,

Marten

[Brigitta Sipőcz]

Hi,

While I'm not arguing for keeping np<2 support, I can also bring another use case where it can cause issues. In this case one or multiple other dependencies doesn support it, and when we talk about end user research code it's not exactly expectable to be able to just fix it all up and practically take on maintenance of random third party libraries; even when we're institutional users.

(And yes, arguably you can say that we then can just stay on 7.x or even on 6.x astropy, but from other parts of it we need the fixes and occasionally the improvements, too). So in my experience it is never about "update your own code to support np 2+"; more like "go back in time and don't pick third party dependencies that are not rigorously maintained"; and for this usually I'm just a small clog in the machine and that decision was out of my hands; and it's not like we have an abundance of choice to pick specialized libraries from -- it all comes down use not well maintained existing and established third party or take on reinventing the wheel. 

That being said, we also do use libraries that are requiring numpy 2+, so siloing the old dependencies into their archaic environment is a workaround that works for now for my example. It's not pretty and not convenient, and I suppose not really applicable for a pipeline environment, but for our end user cases it kind of works.

Cheers,

 Brigitta

ps: this all being said, I still stand by what we wrote for SPEC0 for and personally support the drop of np<2

--
You received this message because you are subscribed to the Google Groups "astropy-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to astropy-dev...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/astropy-dev/87qztmutno.fsf%40dolphin.astro.utoronto.ca.

[James E.H. Turner]

Updating DRAGONS dev to work properly with NumPy 2 has taken months of
work, which has to be fitted around overarching project schedules, so I
wouldn't be surprised if some others are struggling to deal with it. We
should get that out to our users on a similar timescale to AstroPy 8.

I think dropping NumPy 1 seems more viable if we're prepared to continue
merging bug fixes into 7.x for some time to come. Projects like Tom A
describes have stability requirements, often along with limited resources,
but cannot remain completely static in the meantime, so would need to
deal with any critical bugs that might come up. What Marten said yesterday
about DIY LTS might work (we did fix a couple of bugs in 7.x to get our
stuff working on NumPy 2, along similar lines), but it would still need
some review if the point is to keep it stable. There are also the tiny
projects where the original author has left and the current maintainer
may need help until they can get a student/postdoc to rewrite it...

Cheers,

James.

> email to astropy-dev...@googlegroups.com <mailto:astropy-
> dev%2Bunsu...@googlegroups.com>.

> To view this discussion visit https://groups.google.com/d/msgid/astropy-

> dev/87qztmutno.fsf%40dolphin.astro.utoronto.ca <https://groups.google.com/d/
> msgid/astropy-dev/87qztmutno.fsf%40dolphin.astro.utoronto.ca>.

>
> --
> You received this message because you are subscribed to the Google Groups
> "astropy-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email

> to astropy-dev...@googlegroups.com <mailto:astropy-
> dev+uns...@googlegroups.com>.

> To view this discussion visit https://groups.google.com/d/msgid/astropy-dev/

> CAEjJ3fi6QZ%3D5CMd7KNVPnMzRXg2%2BSXB5ZOP70%3Dd00GQZe6x8xg%40mail.gmail.com
> <https://groups.google.com/d/msgid/astropy-dev/
> CAEjJ3fi6QZ%3D5CMd7KNVPnMzRXg2%2BSXB5ZOP70%3Dd00GQZe6x8xg%40mail.gmail.com?
> utm_medium=email&utm_source=footer>.

[Clément Robert]

Not to sidetrack the conversation or anything, but this does sound a lot like people I’d like to get in touch with (and for what it’s worth, my intention is to advocate for them, even, maybe especially, because they don’t get involved in this mailing list).

Clément

[Aldcroft, Tom]

I just wanted to highlight a possible solution that was suggested by Nathaniel in the PR discussion, namely making an interim LTS branch that supports numpy 1.26. I very much like this idea as a compromise that demonstrates a strong commitment to stability for a small but important segment of our community while allowing development on the main branch to proceed efficiently.

This would be essentially a "numpy 1.26 LTS", continuing backports to 7.2.x for another 6 months (TBR) or so after 8.0 is released, as needed from user feedback and as practical.

Are there any objections to this? Obviously this represents a temporary labor increase to support this interim LTS, but we've done it before so presumably the process and labor are tolerable.

- Tom

--
You received this message because you are subscribed to the Google Groups "astropy-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to astropy-dev...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/astropy-dev/7969AB96-5B74-460C-8415-F4367C9194A8%40gmail.com.

[Pey Lian Lim]

(From https://github.com/astropy/astropy/pull/18986#issuecomment-3582633787)

Okay, everyone, let's cool down a bit. We have APEs for a reason. These were extensively discussed in the community and accepted by Astropy Project.

• APE 2 lays out what we're allowed to do in a given feature release.
• APE 18 lays out when we can bump Python and Numpy.
• APE 21 moved us away from LTS.

So far, while I understand the frustration and concerns, I haven't seen a concrete case that warrant this to be delayed to astropy v9.0 even though I don't think any of those APE prevents such possibility.

However, talks of bringing back LTS triggers me because we had extensive discussion to drop it and put that in APE 21. LTS was a lot of extra maintenance. So any talk to bring it back (either temporarily or permanently) is a strong 👎 from me.

If new projects don't want to use astropy because of this or that, it is not our problem. We cannot make everyone happy. If they want to rewrite astropy and maintain it, it is on them. They will probably stumble upon this discussion again on their own at some future time.

If we break existing pipeline though, it is our problem, but we need to know exactly how and help them transition away from numpy 1, if possible.

[Aldcroft, Tom]

Perhaps using "LTS" was an unfortunate choice since that triggers a different mindset. What if we just continue trying to backport bug-fixes to 7.2.x for an additional 6 months with a well-advertised hard stop after that. This will be somewhat more work since there will be concurrent backports to 8.0.x.

While it is certainly true that those APE's have been discussed already and approved, this particular situation was not part of that discussion. The numpy 2.x transition presents an unanticipated issue that requires some thought and flexibility.

I very strongly disagree that it is not our problem if organizations (and individuals) move away from astropy due to perceived stability issues. It is especially concerning to hear that members of a "NASA appointed committee on the future of software in high-energy astrophysics" are steering projects away from using astropy for that reason. Astropy should make a point of reaching out, understanding what drives that perception and addressing it. But in the meantime, assuming a temporary increase in our infrastructure work as a strong signal of our commitment to stability and "enterprise" use of astropy seems very much worthwhile to me.

There is no perfect solution that will fully satisfy everyone. I will say that for Chandra operations, continuing 7.2.x maintenance for an additional 6 months would certainly be helpful. So from my perspective this compromise is the best option. All of the active participants in the PR have agreed.

- Tom

To view this discussion visit https://groups.google.com/d/msgid/astropy-dev/245d3f62-ffa4-487a-b10c-6a6c774571cen%40googlegroups.com.

[Marten van Kerkwijk]

Hi Tom, Pey-Lian, others,

(Copying from
https://github.com/astropy/astropy/pull/18986#issuecomment-3582785577 --
agreed that discussion should be here, not in the issue.)

> I agree with both of you. I think the only thing I would add is that any
> possible temporary LTS has to have a good reason, i.e., we discuss
> problems and possible work-arounds first, with LTS a clear last
> resort. I really mostly want to be sure that the burden of proof is on
> providing concrete problems, not hypothetical ones, and to try to find
> solutions within our standard APE framework. Also, if the problems do
> turn out to be so big that a "7.3" or "7.2.lts" is needed, one can and
> should expect those who really need it to help make it work (i.e., I
> really want to avoid moving work-for-me on keeping numpy 1.x
> compatibility alive to work-for-@pllim in supporting a LTS).

Just to add here, a bit more along Tom's line: I think a good solution
is to release 8.0 with an explicit note that *if there are major
problems upgrading* because of numpy 1.x, we are willing to support 7.2
for a bit longer (and be sure at the same time to ask for volunteers to
help with resolving manual backports, etc.).

But my hope is that none of this will in fact be necessary!

All the best,

Marten

> * APE 2 lays out what we're allowed to do in a given feature release.
> * APE 18 lays out when we can bump Python and Numpy.
> * APE 21 moved us away from LTS.

[Clément Robert]

> Just a request that we should avoid terms such as 'man hours' in these and other discussions - 'person hours' or simply 'hours' should be sufficient.

Of course. I apologise for not realising that myself earlier.

> I very strongly disagree that it is not our problem if organizations (and individuals) move away from astropy due to perceived stability issues. It is especially concerning to hear that members of a "NASA appointed committee on the future of software in high-energy astrophysics" are steering projects away from using astropy for that reason. Astropy should make a point of reaching out, understanding what drives that perception and addressing it. But in the meantime, assuming a temporary increase in our infrastructure work as a strong signal of our commitment to stability and "enterprise" use of astropy seems very much worthwhile to me.

+1 to all of this paragraph.

> *if there are major problems upgrading* because of numpy 1.x, we are willing to support 7.2
for a bit longer (and be sure at the same time to ask for volunteers to
help with resolving manual backports, etc.).

That seems acceptable to me, though we'll still need to agree on what constitutes a *major* problem; to me, "such and such package managers are not able to provide any updates on astropy for the forseable future" would qualify, and an additional 6 month of support for 7.2 would *help*, but may not *solve* it entirely.

My objection would be significantly weaker if we could collectively agree we *might* need to reverse course and re-introduce support for numpy 1 in the 8.x series (post 8.0.0). I'm *also* hoping that won't be necessary, and it's quite certain that it would take more work than to not drop it in the first place, but I'd be much more comfortable with taking a calculated risk than going all-in on it and being unable to backpedal if we loose our bet.

I also strongly feel we should attempt to get inputs from maintainers of package ecosystems (linux distros or others). Their perspective could single-handedly disprove my whole assumption and lift my objection, if it turns out that us requiring numpy 2 isn't causing problems to them.

Cheers

Clément

[Aldcroft, Tom]

Just to add here, a bit more along Tom's line: I think a good solution
is to release 8.0 with an explicit note that *if there are major
problems upgrading* because of numpy 1.x, we are willing to support 7.2
for a bit longer (and be sure at the same time to ask for volunteers to
help with resolving manual backports, etc.).

But my hope is that none of this will in fact be necessary!

Clément started going down the rabbit hole of the conditional "if there are major problems". IMO it shows that we need to make a commitment now for a simple and deterministic path to support 7.2 for one more release cycle (until the release of 8.1).

To rephrase in simple terms:

• Documenting the decision process for triggering continued support for 7.2 immediately opens a host of what-if questions to which there are no easy answers.
• Downstream cannot make concrete development plans if the astropy release schedule is indeterminate.
• Not being willing to publish a definitive release schedule for the next year looks bad for astropy as an organization.
• Polling the user/developer community in a complete and meaningful way is very difficult.

- Tom

[Marten van Kerkwijk]

Hi Tom,

In principle, this sounds reasonable, and I agree in particular with it
being hard to predict the future!

But I'd rather hear from the release team whether they think it is
reasonable, since effectively this pushes extra work on them (and, as
@pllim noted, it is not as if our APEs do not give a clear picture of
what to expect).

I guess in part it depends on what we mean by "support". Backporting
everything that would go to point releases for 8.0? Or limiting
ourselves to truly horrible bugs and items that people report are
required to keep using 7.2? The latter might make the burden for the
release team quite light, since if no horrible bugs are found (very
likely) and no problems are reported (also likely, in my opinion), not a
single extra point release will be needed. It also might help that in
that case one can be clear up front that reporting problems will mean
being asked to help with resolving manual backports, etc.

Anyway, my overall goal remains to ensure no work is done if there are
no problems!

All the best,

Marten

"Aldcroft, Tom" <tald...@gmail.com> writes:

> Just to add here, a bit more along Tom's line: I think a good solution
> is to release 8.0 with an explicit note that *if there are major
> problems upgrading* because of numpy 1.x, we are willing to support 7.2
> for a bit longer (and be sure at the same time to ask for volunteers to
> help with resolving manual backports, etc.).
>
> But my hope is that none of this will in fact be necessary!
>
> Clément started going down the rabbit hole of the conditional "if there are major
> problems". IMO it shows that we need to make a commitment now for a simple and
> deterministic path to support 7.2 for one more release cycle (until the release of 8.1).
>
> To rephrase in simple terms:
>

> * Documenting the decision process for triggering continued support for 7.2 immediately

> opens a host of what-if questions to which there are no easy answers.

> * Downstream cannot make concrete development plans if the astropy release schedule is
> indeterminate.
> * Not being willing to publish a definitive release schedule for the next year looks bad for
> astropy as an organization.
> * Polling the user/developer community in a complete and meaningful way is very difficult.
>
> - Tom

[Aldcroft, Tom]

On Thu, Nov 27, 2025 at 10:02 AM 'Marten van Kerkwijk' via astropy-dev <astro...@googlegroups.com> wrote:

Hi Tom,

In principle, this sounds reasonable, and I agree in particular with it
being hard to predict the future!

But I'd rather hear from the release team whether they think it is
reasonable, since effectively this pushes extra work on them (and, as
@pllim noted, it is not as if our APEs do not give a clear picture of
what to expect).

About the APEs,  again they did not foresee this somewhat unique situation of a breaking change in the most important core library in scientific Python. It is worth noting that I cannot find any other major project that is dropping support for numpy 1.26. I didn't look *very* deep, but all projects in https://learn.scientific-python.org/contributors/setup/ecosystem/ still support 1.26 based on dependencies show in github main. It's a real question whether astropy should be leading the pack in dropping support, but I think our compromise solution is OK.

About extra work, I believe that most or all of the release managers are funded, which changes the picture from asking volunteers to do additional work. Instead this is a question of whether the project considers this a priority and is willing to fund the additional effort. So getting a quick estimate from the release managers on the additional hours required would be quite helpful.

 

I guess in part it depends on what we mean by "support".  Backporting
everything that would go to point releases for 8.0?  Or limiting
ourselves to truly horrible bugs and items that people report are
required to keep using 7.2?  The latter might make the burden for the
release team quite light, since if no horrible bugs are found (very
likely) and no problems are reported (also likely, in my opinion), not a
single extra point release will be needed.  It also might help that in
that case one can be clear up front that reporting problems will mean
being asked to help with resolving manual backports, etc.

Defining "horrible" again just brings uncertainty and confusion to the process. Instead, do the same thing we always do and mark all bug-fixes for backport to the appropriate branches. When there are no merge conflicts this is a low-effort process. When there are conflicts then it is up to the PR author to resolve the conflict or else justify that the bug does not require backport. This is what we do now and is a well-practiced process. The difference is backporting to an additional branch and increased likelihood of conflicts.

 

Anyway, my overall goal remains to ensure no work is done if there are
no problems!

Again, telling downstream that continued 7.2 releases will depend on unknowns like whether someone reports a problem or whether some authority decides that some bugs meet some undefined threshold of horrible-ness would only introduce frustration IMO. 

I think we have three choices:

1. Announce that 7.2.x bug-fix releases will continue until the 8.1 release, following the long-established process for backporting all fixes if practical.
2. Drop support for numpy 1.6 now in main and provide no further support in releases beyond 8.0.
3. Keep support for 1.6 in astropy 8.x and drop it in 9.0.

I vote for (1), but not for a squishy version of (1) that includes vaguely defined contingencies.

- Tom

 

All the best,

Marten

"Aldcroft, Tom" <tald...@gmail.com> writes:

>  Just to add here, a bit more along Tom's line: I think a good solution
>  is to release 8.0 with an explicit note that *if there are major
>  problems upgrading* because of numpy 1.x, we are willing to support 7.2
>  for a bit longer (and be sure at the same time to ask for volunteers to
>  help with resolving manual backports, etc.).
>
>  But my hope is that none of this will in fact be necessary!
>
> Clément started going down the rabbit hole of the conditional "if there are major
> problems". IMO it shows that we need to make a commitment now for a simple and
> deterministic path to support 7.2 for one more release cycle (until the release of 8.1).
>
> To rephrase in simple terms:
>
> * Documenting the decision process for triggering continued support for 7.2 immediately
>  opens a host of what-if questions to which there are no easy answers.
> * Downstream cannot make concrete development plans if the astropy release schedule is
>  indeterminate.
> * Not being willing to publish a definitive release schedule for the next year looks bad for
>  astropy as an organization.
> * Polling the user/developer community in a complete and meaningful way is very difficult.
>
> - Tom

--
You received this message because you are subscribed to the Google Groups "astropy-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to astropy-dev...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/astropy-dev/y2jldjrecxi.fsf%40swan.astro.utoronto.ca.

[Pey Lian Lim]

I really want to hear from Tom Robitaille (who handled the last release and was involved in writing most of the mentioned APEs) and the new CoCo7.

My vote is (2) or (3). For (3), if other Scientific Python libraries (e.g., scipy) have not dropped numpy 1 yet, it is a strong indication that we should not also; and I don't see how it is going to kill us supporting old code for another year or so. 

I am not thrilled with (1) because it sets a precedence of accepting APE and then kinda ignoring it.

[Marten van Kerkwijk]

Agreed that I would really like to hear from those doing the release!

My vote is for (1) or (2), depending on that.

Also, just in case, before we assume that the rest of the ecosystem is
ignoring SPEC 0 for numpy 2.0 and keep on supporting numpy 1.x for a
while longer (which would be very relevant), I'd like to be sure that
that is not just the effect of looking *now*, only a month or so after
one was supposed to be able to drop numpy 1.x, i.e., whether others are
planning to keep support also after April, or whether they intend to
drop support by then but just haven't gotten around to actually do it
(since for them presumably it is also several hours of work even just to
remove the compatibility code...).

-- Marten

> 1 Announce that 7.2.x bug-fix releases will continue until the 8.1 release, following the

> long-established process for backporting all fixes if practical.

> 2 Drop support for numpy 1.6 now in main and provide no further support in releases
> beyond 8.0.
> 3 Keep support for 1.6 in astropy 8.x and drop it in 9.0.

[Aldcroft, Tom]

On Fri, Nov 28, 2025 at 12:22 PM Pey Lian Lim <p3y...@gmail.com> wrote:

I really want to hear from Tom Robitaille (who handled the last release and was involved in writing most of the mentioned APEs) and the new CoCo7.

My vote is (2) or (3). For (3), if other Scientific Python libraries (e.g., scipy) have not dropped numpy 1 yet, it is a strong indication that we should not also; and I don't see how it is going to kill us supporting old code for another year or so. 

Choosing (3) won't kill astropy, it seems credible that (3) will make Marten less enthusiastic about spending time on astropy. Or else cost astropy money for added time in Cycle 5: Quantities with Array API support, Improved Support for Masks and Uncertainties.

 

I am not thrilled with (1) because it sets a precedence of accepting APE and then kinda ignoring it.

You are right that formally speaking, this would require an update to the affected APE's. So that would be a fine option that strictly follows our APE process. If there is sufficient consensus to move forward with (1) then I would be happy to open a PR.

 

- Tom

To view this discussion visit https://groups.google.com/d/msgid/astropy-dev/0817913e-8731-4c0d-8991-7ed13692c6b8n%40googlegroups.com.

[Aldcroft, Tom]

It is possible we are approaching the limits of what can be decided in an email/GH thread.

There is an astropy dev telecon next Wednesday Dec 3 at 9am EST. Are most of the key stakeholders in this discussion available then? If so, that might be a good chance to try reaching a consensus.

- Tom

[Timothy Pickering]

i dug a little deeper into the greater ecosystem and found that the main branch for pandas, scipy, and scikit-image is set to numpy >= 2.0. scikit-learn, zarr, and matplotlib are still >= 1.x on main. so we're in a bit of a twilight zone and i think can reasonably go either way. given probable community concerns i would lean towards (3), but would be ok with (2). i'm with pey lian on not being a fan of (1). keeping support for numpy 1.x around until 9.0 seems a path of lesser resistance if we do want to keep it around. that would also allow us to more clearly advertise that 8.0 is that last release to support numpy < 2.

tim

[Aldcroft, Tom]

On Fri, Nov 28, 2025 at 1:36 PM Timothy Pickering <te.pic...@gmail.com> wrote:

i dug a little deeper into the greater ecosystem and found that the main branch for pandas, scipy, and scikit-image is set to numpy >= 2.0. scikit-learn, zarr, and matplotlib are still >= 1.x on main. so we're in a bit of a twilight zone and i think can reasonably go either way. given probable community concerns i would lean towards (3), but would be ok with (2). i'm with pey lian on not being a fan of (1). keeping support for numpy 1.x around until 9.0 seems a path of lesser resistance if we do want to keep it around. that would also allow us to more clearly advertise that 8.0 is that last release to support numpy < 2.

Hi Tim,

I'm not an expert in build infrastructure, but my interpretation of what I found was that pandas, scipy and scikit-image at main all allow numpy 1.26.

• https://github.com/pandas-dev/pandas/blob/1b5b02c08bef32dd93c2ee3553c9d93be1a71818/pyproject.toml#L29
• https://github.com/scipy/scipy/blob/2bd64d7f26624261c121ac96a0605a872b5e0a84/requirements/default.txt#L3
• https://github.com/scikit-learn/scikit-learn/blob/c3b0873dfdd42e4d30f60e44bdab238d617a7130/pyproject.toml#L10

Maybe I am out of depth answering that question. In a couple of cases the *build* requirement was for numpy > 2.0.

- Tom

 

To view this discussion visit https://groups.google.com/d/msgid/astropy-dev/74affc07-6aa6-45d5-8bd0-18a451475292n%40googlegroups.com.

[Timothy Pickering]

i just was looking at the numpy dependency in their pyproject.toml files and what version it was pinned to. 

tim