On 5 January 2015 at 17:38, Peter Dimov
Yes, I knew about this file. I'm not sure, however, what is the point of the pre-library meta/libraries.json files then, as they contain (a subset of) the same information.
It's so that this data can be managed by the library maintainers. Currently I have to do quite a lot of admin just to add a new library or change the details. And people don't realise they have to let me know when something has changed. Often the first time I would realise is when someone complains after the release. Eventually I want to also generate libs/libraries.htm and lib/maintainers.txt from it. I really should get round to doing that soon-ish, it's pretty awkward that it's part of the website.
I had assumed that we'll be transitioning away from centrally stored files, and will be generating everything from the individual modules themselves. So, under that assumption, I expected the info in libraries.xml to be moved to the appropriate meta/libraries.json files, and then disappear.
Maybe, but I never envisioned this as a full solution. If we have a full package system, it might want to use a different file format. When I set this up, it looked quite likely that it would be based on a third party system that would use something completely different, or that the implementer would want to design their own file format. I also didn't want to force it on anyone, anyone who didn't accept my pull-request would be very unlikely to keep the file up to date.
Historical data is handled centrally, so it would be redundant and error prone to store it in the library repos (e.g. if a library was pulled from a release, but wasn't updated accordingly).
Right... but what is the point of the json files then?
Answered earlier. I'm not sure why a package manager would need to know when a library was first released.
Wait, I think I figured it out... the release script generates (would generate) the release-specific info from the json files, then puts (would put) that into libraries.xml?
Sort of, it can also be updated from the beta and master branches.
But I see how this might create a problem for the script that generates libraries.xml, and I also see why we can no longer change "workarounds" to "Workarounds" for consistency.
Could make it case insensitive. It probably should be.
A compromise might be to add category_name: [] to the json files and keep the current category: [] as is. Or, I could just hardcode the names and be done with it. :-)
It shouldn't be too hard to automatically update the names, or add them as part of the release process.