APE 18: Adopt NEP 29 - #63

The core astropy package as well as other coordinated and infrastructure packages will support

This is perhaps something different from APE 10, that this would be project wide

I would not force infra and coordinated to follow this, e.g. they currently usually support more, especially the infra packages.

So I would just go that they can't drop more than what is suggested in NEP29, but they could still support older versions of they want to

Yeah, not sure how we can enforce this project-wide in a realistic manner. We barely have enough people to maintain the core as it is.

Maybe we should say the "rule" applies to core, but coordinated&infrastructure packages will "aim" to follow this unless there's a reason not to? I.e. just say for everything else it's a guideline.

I think the virtue of that is that it gives some guidance for packages that are sort of like "we don't have a rule because we haven't really thought that deeply about it". Or alternatively/additionally, it provides an excuse to ask institutional players to help us bring things "up to standard" (I'm thinking here about how the py 3.x transition provided some people at institutions a way to fund additional work by existing Astropy devs)

many of the infra packages didn't really have a reason to drop old versions for a while, and I fail to see why it would be different in the future. As I said above, in many cases dropping a version is more work than keeping it, thus the "aim" is problematic in practice. And frankly, what is important for the ecosystem is that all coordinated and infra support at least the NEP29, that there is no situation when something gets dropped sooner than this schedule.

Agree we can make it a rule for core and recommendation for other parts of the project?

if they have a reason to still support 3.4, then why not

Just thinking about #10888 that I just put in, which would require 3.7+ for astropy to work properly. If a coordinated package tries to force using Python 3.4 + astropy 4.2 then there will be problems. Not sure if that is credible.

I'm not sure what you mean credible here, it's always up to the package manager to resolve the version requirements, I don't see any force being involved here.

E.g. on 3.4, it could be possible to install the latest version of a coordinated package, and naturally, it would come with an older astropy version. It's down to the CI of the coordinated package to make sure they are compatible with their minimum supported version combination, after all the user should know best why they are stuck on an older python/numpy combo.

(3.4 is probably a bad example, but a real life example, with astroquery we had to stay python2.7 compatible much much longer than astropy core as it took long for casa to move off it. We, the astroquery maintainers decided that it's something we were willing to do, and it was totally independent of the version support policy of core that was decided separately. )

While I'm fine with this, I think it might be good to give at least one concrete example of a way the more "accelerated" schedule will help things. Like what py3.7 features would we want to implement sooner rather than later? (manylinux2010 might be the answer! Or data classes?)

I added a small justification in the backwards compatibility section, I don't really want to do a "let's adopt 3.7 because new features things" because I would rather this stand the test of time. I am happy to pull the justification section up here if you think it's a better place for it?

I see your point on "stand the test of time", but I was thinking the point of this is to give a couple of concrete examples to what is currently a very abstract phrasing. So just meant something like "For example, at the time of the py3.7 release infrastructure maitainers found their life would be easier if manylinux2010 was an option". Or similar.

But if you really want it to be timeless, I'm ok with either pulling it up here or leaving as-is 🤷.

this is the change I was asking for clarification of in https://github.com/astropy/astropy-APEs/pull/63/files#r506624591

Maybe worth saying since these are currently supported for two years (in case we change that some day)

I find this phrasing very confusing.

What about rewording to say the 42 and 24 are for the start of a release "family", and support won't be dropped in a bugfix release, neither on LTS nor on normal feature release bugfix?

(also, I promised Stu a blurb about the exceptation, e.g. the latest LTS dropped a numpy version the release, as it would have been dropped based on NEP29 very soon after the release)

What about rewording to say the 42 and 24 are for the start of a release "family", and support won't be dropped in a bugfix release, neither on LTS nor on normal feature release bugfix?

👍 This is in NEP 29, but I am happy to call it out here in terms of the LTS if people feel it needs more clarity.

I disagree that it's very clear in NEP 29 for the casual reader. That is it's very specific and when I read very carefully I understand the above, and really anyone in this conversation is clearly interested enough to dig deeply on this. But I do not think the typical reader who comes upon this via google and just wants to know "how long will an astropy support this Python version" will take the time to click through to NEP 29, map it onto our Astropy-specific release candence, etc.

That said, if y'all think this wording is not clearer, maybe the better thing is to just give a few concrete examples and let the reader extrapolate? Something like:

Or @cadirS wording from https://github.com/astropy/astropy-APEs/pull/63/files#r506678119 makes sense to me too.

See my extra sentence about the bugfix lifetimes.

(I don't find these concrete examples any useful, try to swap it out with e.g 1.3 and it will all read obsolete for the casual reader who you say would not bother to read/try to understand the tables and figures in NEP29)

There is a line now stating that the versions are supported for the lifetime of the bugfixes, so hopefully that resolves the core of your comment @eteq in a way people are happy with?

Reads well to me.

Reads well to me.

I guess this line does need to be changed.