Automatically update icon packs based on their Github Releases

[martijnarts]

This would use Renovate (as suggested here: #37 (comment)).

I'm working on this, just opening the thread for discussion!

[martijnarts]

@carloskiki I'm probably missing something obvious. Are you doing anything special to develop on this library? I can't get rust-analyzer to give me any support!

[carloskiki]

@martijnarts Basically, all crates are just a bunch of statics that are generated from the build/ binary. To run it you can either cd into the directory and cargo run or you can run just build from anywhere (using just). In general, you should not be modifying any of the files that are generated by the binary, you should instead modify the templates in build/templates in order for the changes to be reflected once just build is ran.

I'm not sure of what you mean when you say RA doesn't work, but from my experience it works very well in the build crate. Of course it may struggle when used in a file with 10 000 lines of raw strings and statics, I'm not sure it's meant to be used that way 😅.

Do not hesitate to notify me when you need help or you have made some progress :).

[mondeja]

What would be the desired versioning strategy for these updates?

[pyrox0]

As an upstream user of icondata, I think it would be best if each crate was versioned based on the upstream version, or at least give some way of notating which upstream version/icondata version an icon pack is from. So for instance, icondata_si(the simple icons pack), would go to version 14.15.0(the latest upstream version at the time of writing), or 0.5.0-14.15.0/something similar, which tells me it's icondata version 0.5.0, and upstream pack version 14.15.0. Then as upstream makes new releases, generating new versions would be easy, as you just get the latest release, grep for and replace the old version numbers, and then push the new release, all of which can be done from github actions. This would make it easier to maintain and keep every crate up to date with new upstream releases, as all the crates currently are fairly outdated.

[carloskiki]

@pyrox0, the issue with what you suggest is that then we cannot update the architecture behind these crates (not that I was thinking of doing that), but say if we want to introduce traits or other enhancements.

I think matching versions is only worth it when the libraries are not up to date (which they are not currently). If we end up having an automatic release system then the icon packs would always be at their latest release. The only benefit would be in looking for deprecated icons that are only available in old versions.

I currently do manual updates infrequently, hence why having an automatic update mechanism would be awesome.

[carloskiki]

What would be the desired versioning strategy for these updates?

I think we could either try to match the semver policy of each icon pack (not necessarily matching the version numbers, just match the increase in major/minor/patch version), this would be tedious but doable. Or we can just introduce a breaking change every time an update is done, and let the users deal with that. I think we can start with the latter and then decide if it is worth it to try doing the former. Something like publishing 0.x.0 every update would be nice already.

On a related note, I don't know whether we want to keep the icondata crate, including icondata = { version = "...", features = ["ai", ...] } is just the same as icondata_** = "...", and is easier to maintain for us.