-
Notifications
You must be signed in to change notification settings - Fork 12
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
Write a PHEP to describe PyHC's Python & upstream package support policy akin to SPEC 0 #21
Comments
Following up on this...we should write a PHEP! It would be helpful for the heliopythoniverse to be on the same page, especially the core PyHC packages. It'd also be worth mentioning SPEC 0 which is similar to NEP 29. SPEC 0 recommends that support for Python versions be dropped 36 months after their initial release (in contrast to 42 months in NEP 29) and support for core package dependencies be dropped 24 months after their initial release (though a newer minimum version can be required if there is a critical bugfix). Another consideration is the status of Python version. At the moment, Python 3.7 is past its end-of-life and Python 3.8 will be EOL in October 2024. |
Should be nice and easy "PyHC adopts SPEC-0 in it's entirety" look I wrote it 😜 |
I fully support this! We currently have that standard that packages should strive to support Python 3 instead of 2. That's clearly outdated. I'd say this new PHEP should replace that standard. SPEC-0 seems well thought out. I don't really have the cycles the focus on this until after the Summer School, but afterwards I'd like to move forward with this. |
This is already in progress through @sapols 's work on PHEP 3, yes? Should we close this issue? |
@jibarnum note above how it says "linked a pull request on Jun 6 that will close this issue". GitHub will automatically close this issue once PHEP-3 is merged. |
ahhhh didn't even notice. thanks @sapols ! |
We could update the standards to include something akin to NumPy Enhancement Proposal 29 (NEP 29), which states that packages should work on all minor versions of Python released at keast up to 42 months prior and all minor versions of NumPy released at least up to 24 months prior. NEP 29 balances the need for having a well-defined window of supported versions with the need for being able to adopt new language features, depend on newer packages, and reduce maintenance burden. We might consider extending this to include packages like Astropy and the core PyHC packages for our standards.
A consideration is that some missions have a strong need for stability with mission-related software. NEP 29 is a minimum, and nothing would preclude packages from continuing to support older versions of NumPy & Python when there is a need for it.
Update: edited the title to refer to SPEC 0, which has superseded NEP 29.
The text was updated successfully, but these errors were encountered: