Aim for SPEC0 adherence over NEP29

[orbeckst]

trafficstars

Implement SPEC0 (instead of NEP29)

• SPEC0 describes minimal support for Python and other package versions across the eco-system
• We already follow NEP29 which appears to be a superset in some regards but leaves other parts undefined — see below.

TODO

• [ ] CHANGELOG note
• [ ] public annoucement
• [ ] modify CI (??)

Discussed in https://github.com/MDAnalysis/mdanalysis/discussions/4466

^{Originally posted by IAlibay February 24, 2024}

Background

As outlined here: https://github.com/numpy/numpy/issues/24932#issue-1943808025 the NEP29 enhancement proposal has been superseded by SPEC0.

There is very little difference between the two, except that SPEC0 has a shorter support window (3 years for Python, 2 years for core packages) than NEP29 (42 months for Python, and 2 years for NumPy). SPEC0 also defines support windows for a wider range of core packages (e.g. scipy, matplotlib, etc..).

How would this affect MDAnalysis?

In practice this would have very little impact. The difference between NEP29 and SPEC0 is small enough that we would be unlikely to see anything given our release frequency.

The main thing would be that we would be basing decisions to drop support for Python & other upstream dependency versions on the SPEC0 schedule rather than the NEP29 one. It would also mean that the day I finally get to write this blog post it would be about SPEC0, not NEP29.

Does this mean we have to strictly adhere to SPEC0?

The idea here is that SPEC0 defines the "minimum range of versions which should be supported", rather than "the only things that should be supported".

That means that we can support a wider range of dependency versions if we wish to. This would be up to the community to help define.

What if we don't adopt SPEC0

We could stick to NEP29 or seek alternative schemes to define what range of core dependency versions we support.

[IAlibay]

@orbeckst I'm not sure any of those steps need to be taken? I'll self assign here but I don't particularly think anything needs to change (edit: here I'm thinking of CI and changelog), SPEC0 is a minimum bound not a maximum one.

[IAlibay]

Maybe the public announcement - although that's a low priority task we can deal with at the next release?

[orbeckst]

Please by all means change the issue and just take the necessary steps—if less work is needed, great. I wanted to make sure that we have an actual issue item instead of discussion after we decided something. At a minimum we have to communicate that we will follow SPEC0. IIRC historically we used CHANGELOG to record changes in support policy so that’s why I listed that. If a short blog post announcement is useful then we can do that, too. Am 3/28/24 um 01:23 schrieb Irfan Alibay @.***>: @orbeckst I'm not sure any of those steps need to be taken? I'll self assign here but I don't particularly think anything needs to change, SPEC0 is a minimum bound not a maximum one.

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>

[IAlibay]

IIRC historically we used CHANGELOG to record changes in support policy

Ah, this isn't something I've encountered before (unless I've missed it happening).

At a minimum we have to communicate that we will follow SPEC0

My suggestion is to tie it in to the next release. We can mention it on the release thing and then if we have energy tag on a separate blog post - ideally this is tied into a release strategy (i.e. it might not be very meaningful for us to talk about SPEC0 without telling folks about what we engage ourselves to do when it comes to releases - if you follow SPEC0 but release every 24 months then that's a bit of a problem, etc...).

[IAlibay]

To clarify my stance on "modify CI" - my view here is not to touch dependencies unless we have to. I.e. if we think "o we really need this feature from X" then we increasing the lower bound, otherwise we just periodically bump stuff up if it's really too old (i.e. a scipy version that isn't compatible with any of the numpy versions we support).

Alternatively, we can done on strict bump now and then be looser afterwards? Not sure.

[orbeckst]

Looser CI is fine with me, as you said, "lower bound".

[orbeckst]

Announcements in CHANGELOG could have been clearer... eg 2.1.0 introduced NEP29 https://github.com/MDAnalysis/mdanalysis/blob/f5335b4db7f6f746f163e3a617ae6658d30d2fb9/package/CHANGELOG#L613-L614 but for other projects I (or we??) had a "Changes: we now follow NEP29".

[IAlibay]

Ok sounds good, I'll do a review of our stack after we fix the tests & testsuite problems. We can bump up anything that's completely out of range & add a changelog entry.