Closed connortann closed 1 year ago
Agree that we should have a changelog. That should be part of the pre-requisites before the next release.
I'm more inclined towards a separate changelog file though. And I'ld suggest putting the changelog into the docs.
I prefer the README to be a little leaner (just my preference).
The changes that we've made thus far are mostly bug fixes and not noteworthy enough (IMO) to be placed in the README. If we introduce new features or change the API, then I think we can highlight it in the README.
Maybe see https://github.com/yt-dlp/yt-dlp#readme for an example (I do think their README is way too long, but just trying to illustrate the point that they, as a fork repo, is only highlighting new features).
Thanks for that example, I hope we can do something similar to yt-dlp!
I actually think that it is noteworthy that our fork only has bug fixes. If I were looking for a version of SHAP to use in a project, it would be really reassuring to know that it is close to the original but with bug fixes and working tests.
So, on top of a detailed changelog, I hope that we can at least summarise the main changes in the Readme.
I'm open to having something short in the README. It could be nice to highlight the main improvements in the README (even if they are comparatively minor), like fixing warnings, tests, and setup.
I think it would help to have a bit more info on the README to explain what is different about this fork compared to the original repo.
What do you think about having a condensed changelog, to show the various issues that have been fixed? This could help give other developers or users a clearer sense of what has changed, and give them confidence in what has not changed (e.g. that the API remains the same).
It could either be a summary in the README, or perhaps a separate changelog. I'm inclined to go for the main README for visibility. I'd recommend the standard format from https://keepachangelog.com/en/1.0.0/