Address @shoyer's comments on SPEC 0#409
Address @shoyer's comments on SPEC 0#409jarrodmillman wants to merge 3 commits intoscientific-python:mainfrom
Conversation
bsipocz
left a comment
bsipocz
left a comment
There was a problem hiding this comment.
I see that this is still a draft, but maybe you still find my comments useful.
| "drop_date": datetime.strptime(release_date, "%b %d, %Y") + plus36, | ||
| "drop_date": datetime.strptime(release_date, "%b %d, %Y") + plus24, |
There was a problem hiding this comment.
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
spec-0000/chart.md
Outdated
| 3.12 : 2023-10-02,2026-10-07 | ||
| 3.13 : 2024-10-07,2026-10-07 |
There was a problem hiding this comment.
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
added
SPEC Discussion
Discuss in meeting
|
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. |
|
@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): |
|
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. |
|
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. |
4 participants
Close #190. The committee opted to reject this PR. I will remove the related content in #389.