APE 18: What does it really mean for other runtime dependencies?

[pllim]

This sentence in APE 18:

Versions of other runtime dependencies released 24 months prior to a non-bugfix release.

I guess I cannot understand what "prior to a non-bugfix release" mean. I need examples.

As of writing this, astropy has this in its setup.cfg and 24 months ago was Nov 2020:

• pyerfa>=2.0 -- This was released in May 2021. 24 months ago includes 1.7.1.1. So, why not 1.7?
• PyYAML>=3.13 -- It is 6.0 now. 3.13 was released in July 2018. Why didn't we bump to 5.4 (released Jan 2021)?
• packaging>=19.0 -- It is 21.3 now. 19.0 was released in Jan 2019. Why didn't we bump to 20.5 (released Nov 2020)?

Do the optional dependencies count as "runtime" dependencies or we only bump as needed?

xref astropy/astropy-tools#177 and astropy/astropy#13930

[Cadair]

I guess I cannot understand what "prior to a non-bugfix release" mean.

It means the versions don't change with bugfix releases, so you determine version support based on the expected release date of a major version.

pyerfa

I assume this is because it's a dependency we maintain and we needed to bump it outside the regular cycle.

PyYAML and packaging

Update them!

Do the optional dependencies count as "runtime" dependencies or we only bump as needed?

I would say yes they count.

---

I don't feel that the actual APE text needs to be much more prescriptive, I think this is just a core package process issue where all these deps should get a bump before feature freeze.

[pllim]

I would say yes they count

That is a lot of packages to check. 👀

[bsipocz]

pyerfa

I assume this is because it's a dependency we maintain and we needed to bump it outside the regular cycle.

It shouldn't matter who maintains the dependency. If it's a dependency, and there is a guarantee pledged that 2 years are supported, then there should not be bumps outside the cycle.

[Cadair]

then there should not be bumps outside the cycle

"... without good reason" I think there is always exceptions (cost of maintaining backwards compatibility as a single example).

Also I don't know if that's the reason pyerfa was bumped, I was just guessing why it might be ahead.

[Cadair]

I would say yes they count

That is a lot of packages to check. eyes

That's what we get for having too many dependencies ;) We should probably automate it!!

[pllim]

We should probably automate it

I started astropy/astropy-tools#177 but it is not obvious to me how major version bump should be handled.

[Cadair]

how major version bump should be handled

I am not sure I understand, the wording of the APE is pick the version released in a given window of time (arguably ignoring bug fixes).

[pllim]

But not all packages follow semver, so I have to code it up on a case-by-case basis?

[Cadair]

You could code it up not ignoring bug fixes and that would also be fine (certainly a lot better than not having it at all).

[pllim]

I'll have to ponder this more when/if I have time... Feel free to take what I have and run with it, or propose your own check, if you get to it before I do.

[pllim]

There might be a better script here: https://scientific-python.org/specs/spec-0000/

• SPEC 0: report minimum versions, instead of what to drop scientific-python/specs#211