-
Notifications
You must be signed in to change notification settings - Fork 54
Address @shoyer's comments on SPEC 0 #409
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
bsipocz
left a comment
There was a problem hiding this 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.
| "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.
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
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.
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.
|
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. |
Close #190. The committee opted to reject this PR. I will remove the related content in #389.