Skip to content

Conversation

@jarrodmillman
Copy link
Member

@jarrodmillman jarrodmillman commented Dec 2, 2025

Close #190. The committee opted to reject this PR. I will remove the related content in #389.

  • Get feedback on text at SPEC Planning Meeting (2-12-25)
  • Fix script to conform to the updated recommendation

@jarrodmillman jarrodmillman marked this pull request as draft December 2, 2025 15:44
Copy link
Member

@bsipocz bsipocz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see that this is still a draft, but maybe you still find my comments useful.

Comment on lines -97 to +104
"drop_date": datetime.strptime(release_date, "%b %d, %Y") + plus36,
"drop_date": datetime.strptime(release_date, "%b %d, %Y") + plus24,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe some comments in the code would be nice to make it clear that the drop dates are timed from the release of the next version as it's not clear from anywhere here

Comment on lines 8 to 9
3.12 : 2023-10-02,2026-10-07
3.13 : 2024-10-07,2026-10-07
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

there must be a bug here somewhere, we don't cover the case of what happens when there is no next release yet. IMO with the no logic there should not be a drop date.

@bsipocz bsipocz added SPEC Discussion Discuss in meeting Discuss in a SPEC committee meeting labels Dec 2, 2025
@keewis
Copy link

keewis commented Dec 2, 2025

In case it is helps, I maintain a github action that checks CI environments against this version of the policy: https://github.com/xarray-contrib/minimum-dependency-versions (example run). The release dates are taken from conda-forge so they are not fully accurate but usually good enough. I still have to figure out how to deal with packages that are on PyPI but not on conda-forge, though.

@bsipocz
Copy link
Member

bsipocz commented Dec 2, 2025

@keewis - not sure if you saw it, but we have a GHA for spec0 as a tool, too (though it's still rather new so I expect there can be plenty room for improvements -- contributions are more than welcome):

https://github.com/scientific-python/spec0-action

@stefanv
Copy link
Member

stefanv commented Dec 2, 2025

My understanding is that the purpose of this change is to accommodate core packages that, for some reason, stop releasing frequently. So, you can e.g. end up in a situation where you drop support for the only version available.

This is a concern perhaps for smaller packages, but almost per definition we can expect a regular cadence of the core packages. And, since we don't make a recommendation for non-core packages, I don't consider this a crucial change, unless there is another reason for making it.

@jarrodmillman
Copy link
Member Author

In the SPEC Planning Meeting (2-12-25), the committee members decided to not accept this PR. If the anyone has strong objections to this, it is recommend that they first gather community support (particularly from the Core Projects) and then create a new PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Discuss in meeting Discuss in a SPEC committee meeting SPEC Discussion

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Address @shoyer's comments on SPEC 0

4 participants