search

astropy / astropy-APEs

A repository storing the Astropy Proposals for Enhancement.
Other
35 stars 37 forks source link

APE 18: Adopt NEP 29 #63

Closed Cadair closed 3 years ago

Cadair commented 4 years ago

The future is now.

Fixes #62

Rendered Version

The following table shows the next few releases of the astropy core package and the versions of CPython and Numpy it will support under this proposal:

Astropy Release Release Date CPython Version Numpy Version
4.2 November 2020 3.7+ 1.17+ (Historical)
4.3 April 2021 3.7+ 1.17+
5.0 (LTS) November 2021 3.7+ 1.18+
5.1 April 2022 3.8+ 1.19+
5.2 November 2022 3.8+ 1.20+
5.3 April 2023 3.9+ 1.20+
pllim commented 4 years ago

Does this fix #62 ?

pllim commented 4 years ago

Does this mean we also have to retire APE 10 when this is accepted?

Cadair commented 4 years ago

Does this fix #62 ?

yes

Does this mean we also have to retire APE 10 when this is accepted?

Pass

pllim commented 4 years ago

What does "pass" mean?

5.0 and 6.0 are LTS, right? If so, it should be stated as such in your APE.

Cadair commented 4 years ago

Does this mean we also have to retire APE 10 when this is accepted?

I state that this APE has precedence over 10 but I don't know what the rules are on retiring APEs.

5.0 and 6.0 are LTS, right? If so, it should be stated as such in your APE.

Added

pllim commented 4 years ago

I don't know what the rules are on retiring APEs.

Hopefully @astropy/coordinators and/or @perrygreenfield know...

pllim commented 4 years ago

Wait a minute... why is APE 9 in the diff?

Cadair commented 4 years ago

whoops, think that was on my master branch

saimn commented 4 years ago

:+1: to this, just two comments:

Cadair commented 4 years ago

I think Python adopted the PEP for yearly releases, and I'm not sure how it affects NEP 29.

I think NEP 29 saw this coming hence they decided on a time based scheme, rather than one tied to the CPython release schedule. So I think the answer is it doesn't.

From the alternatives section of NEP 29:

Given the current release cadence of the Python, the proposed time (42 months) is roughly equivalent to “the last two” Python minor versions. However, if Python changes their release cadence substantially, any rule based solely on the number of minor releases may need to be changed to remain sensible.

bsipocz commented 4 years ago

There has been also some starting momentum for setting maximum versions of dependencies, but it hasn't yet formalized in a formal document. If there will be any, I'm happy to put in a separate APE for it.

astrofrog commented 4 years ago

@Cadair - maybe you can add #10900 under implementation?

Cadair commented 4 years ago

I have adopted @bsipocz's suggestion regarding all the other versions, and edited the text to make it clear we are extending the numpy policy in NEP 29 by doing that. I think given we merged astropy/astropy#10900 there is unlikely to be strong disagreement to this proposal, we should probably move to getting it merged?

mhvk commented 3 years ago

I cannot merge this, but maybe someone who can can do the honour? Thanks, @Cadair!

Cadair commented 3 years ago

@astropy/coordinators Can this get wrapped up?

eteq commented 3 years ago

With the change above, the CoCo was happy to approve this APE, so I am merging now.