I would assume a noop is automated, and the library is no longer maintained.

If, however, I saw a statement at the top of the README that said:

"Update as of 2 months ago: We believe this project to be complete. We are not adding new features at this time, but if you see any issues, please open a ticket, as this project is still under active development as needed"

then I would feel very confident.

Thanks, that's a good point.

maybe commit to a log indicating that the test suite has run correctly as of <today's date>?this assumes you have a useful test suite but also at least indicates that you're still paying attention & trying to ensure your library works

quid custos ipsos custodiet still applies. The fact that your test suite ran in Esolang v27.8 successfully doesn't mean what you-the-consumer want it to mean if the last supported version of Esolang is v96.2. It just means someone down-stack of you is committed to backwards compatibility.

That future version won’t be on the supported versions list anyway.

I think this varies by project.

I personally support every version of my projects.

My goal is not to minimize the effort to myself but to facilitate the use of my software.

I meant the new version of Esolang, v96.2, wouldn’t be explicitly supported by your project.

Ah, also a good point.

Great idea!

Agreed but this definitely isn’t in the interest of library maintainers. If they did so it’d mean they are acknowledging all the currently open issues and deciding to do nothing, which would sometimes cause backlash.

I mean most projects just auto close all issues now. Dunno where this desire to have 0 open issues came from. Seems like in the past projects would mark the issue as unconfirmed and ignore it, now they all want to close the thread and not allow further comments. Almost as if someone is going to judge their open source project negatively for having open issues, which if that has ever happened that person is more insane than the devs practicing this.