Thanks @savente93!

I wonder if we could also provide code for users who want to use this in CI, or from the web, to see how their dependencies are updated (we could do that as a follow-up).

For this PR, we probably want to ensure the machine readable version is published, and link to it from the SPEC.

Sounds good! I'll at least add the file, and mention it in the SPEC as you mentioned. I'll see if I can make a small prototype for using it to update dependencies, I think that's a good idea for making sure the structure is also actually useful.

Sorry, just realized the .json build would have to be part of the build process for scientific-python/scientific-python.org. +1 for making sure it's usable for some practical purpose :)

@stefanv re it being part of the build process. I wasn't able to find any place where the python script was invoked automatically, so I don't know if I should include a trigger or something for it, if so let me know.

@stefanv well I'm glad I did the small prototype because the original format turned out to not be super easy to parse. I've added some explanations and a small example of how you could update the dependencies, though honestly that part is very dependant on what package manager you use, so I didn't make that very expansive.

One note is that because I calculate the next version and then drop the NaNs we end up with one quarter less at the end, but given that that one is quite a few years into the future I didn't think that mattered all that much, but let me know if it is and we'll see what we can do.

One other bit that would be worth discussing, is how this file will be served, and whether we need any metadata. For this mvp, in the examples I just pull the file directly from main, but I will say that that can give quite the headache down the line if the structure every needs to change. I'm not sure how that will be the case, or if we have another way to serve it. In my experience, at least adding a version number to the format (.e.g. "format": 1) and at least offer a bit more flexibility. What do people think? is that useful?

Other than those points, I think this is mostly done, so I'll be looking forward to the review!

@stefanv Do you have an idea of when you'd have time to review this pull request? I'm just asking so that I can make sure I'll be around to make any changes necessary :)

I may be confused, but it looks like the JSON file is recording when to start supporting new releases. Is that correct?

I was confused. It looks like the key "start_date" means the date you start dropping support for the given versions of the package. Maybe that should be "drop_date" or "support_until" or something similar. Thoughts?

It would be nice to make a GH action or something that folks could use. At any rate, it would be great if you could share your small prototype.

The prototype was already included in the index.md in the sh block, but per your request I've also added an example GH flow that people should be able to copy paste if they use the same package manager.

Because the version logic is non-trival, the schedule.json publishes what your next lower bound should be, instead of what versions to drop support for. It is called start_date because it is the first timestamp of the quarter, and includes what your new lower bounds should be, so you can just take those and chuck them in whatever package manager you use. I don't necessarily care whether it is called start_date or something else, but I do think that calling it drop_date is significantly more confusing if we actually publish the new lower bounds instead of which versions to drop support for.

@stefanv @jarrodmillman Sorry for the ping, but is there any chance of a review one of these days? I'd like to move on from this if possible (and also use the result)

Hi @savente93, I'm afraid I'm on leave atm and don't foresee being able to review any time soon. Perhaps someone from the @scientific-python/tools-team could take a look? Or maybe @bsipocz can recommend a reviewer best suitable.

I'm not sure when I can give the attention this needs. As for reviewers I can add this to the agenda of the next specs meeting next week.

The main issue is that I don't believe it belongs to this particular repo as we should try to keep the technical details and tools out of the specs themselves (the current script is already an exception to the rule), but into a separate actions repo or similar (like what we do with the nightly wheels, etc.). So it all points beyond reviewing the diff in this particular PR.

If you could put it on the agenda that'd be great thanks. I'll be happy pour it into whatever form is most appropriate. If there is a reviewer they can discuss it here or if they prefer contact and we can hash it out. I'll wait for further updates