scala/make-release-notes

Automate maintenance of projects-2.xx.md

plokhotnyuk opened this issue · 3 comments

Why not just fix indexing in Scaladex to do it regularly and for all known repos instead of manually making the list of libraries and plugins which adopted the latest release?

Well, note that the manual maintenance of the library list stops once the Scala release goes final (e.g. 2.13.0). After that, we expect people to just use Scaladex (and/or search.maven.org). Even before that time, we have the Scaladex links first on the page, because people may want to use Scaladex anyway.

Regardless, it's still a good question.

Re: the "fix Scaladex" part, I don't maintain Scaladex, I don't want to get involved maintaining it, and I'm not sure if it currently has a maintainer, I fear it may not.

I don't actually even know how often Scaladex re-queries repos and re-indexes them. If you see some shortcoming there, is there a ticket on it? To be honest, I share your distrust of its completeness and up-to-date-ness. Maybe I'm wrong and it works great now, but I can definitely recall when it didn't, I don't know for sure if it's been fixed since.

I think you're right that more automation would make the libraries list easier to maintain. I'd welcome a pull request with a script that queries Scaladex and prints out a list of the 2.13.0-M5 libraries it finds, in a nice concise one-library-per-line format like that in projects-2.13.md. Anyone reading this want to contribute that?

Having that more automated wouldn't help me maintain the list of pending tickets, though, which is actually the part of projects-2.13.md that I care more about. I maintain that because it helps me keep track of the working I'm doing pestering library maintainers, making them aware when others are waiting for them to publish, and offering them assistance with upgrades. It's my to-do list, but I keep it in public so others can see it and help.

When I remove something from the list of pending tickets, it's relatively little additional effort to add it to the list above as well. I could stop, as you suggest, but it wouldn't be that big an effort savings for me.

@smarter points out that Maven Central is also queryable for this: 7a75e98

closing, it's still possible we might return to this and rethink our approach, but in the meantime I don't think we need to leave the ticket open indefinitely