react-native-track-player
react-native-track-player copied to clipboard
[Feature Request] Implement Conventional Changelog for enhanced/automated changelog generation
It seems like we've stopped using GitHub releases? As the most recent release is 2.0.1.
Recommendations
We should either:
- Update the releases section and keep it up to date (with a script on publish?)
- Delete the existing releases if we're no longer using them (if thats a thing?)
Edit: and now that we've merged the 2.2.0-rc's into main
we should probably add release notes for those to the changelog.
@jspizziri at some point we moved towards a CHANGELOG.md
to document new versions -- one reason was that we wanted to eventually make adding your changes part of the requirements to a PR but have not automated that.
One benefit of this is that the changelog lives in a repo and could be easily migrated elsewhere as opposed to Github Releases.. but I understand most people expect to search there.
You also brought up the possibility of using conventional-changelog, what does that generate?
Regarding 2.2.0-RC.. yes! we should soon start working on the changelog + documentation updates for things. We'll likely need to try setting it up from scratch to see what changes are necessary like:
- do we still need to add code for kotlin support
- methods now reject if you haven't setupPlayer yet
@dcvz , that makes complete sense, and for the record I'm 100% onboard with ditching GH Releases (I always use a CHANGELOG.md for the exact reasons you mentioned).
We have a versioned docs website now and I think anyone who is looking at the changelog is savvy enough to know to look in the CHANGELOG.md and the Git tags.
RE: Conventional Changelog
It's a way to autogenerate your changelog based on your commits. If you've noticed my commits are in a weird format, that's why. You can see an example CHANGELOG here which is completely generated from commits like this. You can also:
- Add helper scripts to make it easy to issue commits like that.
- Add linters to ensure commits are in that format in a GH action.
- Add a simple script to autogenerate that changelog every time you cut and push a new version tag.
It's not something that could be implemented retroactively, however we could create a CHANGELOG_ARCHIVE.md
for versions released prior to using the format.
https://discord.com/channels/567636850513018880/600714011318681610/968551787936243774
@dcvz Would you be OK with me deleting all the GitHub releases to avoid confusion? From my perspective, that's the quickest short-term fix for this.
I think that would be fine @jspizziri ! I guess we'd lose some release notes but it'd be for versions no longe supported.
@dcvz awesome. I'll go ahead and do that. I'll download a copy of all the release notes from the past for historical purposes. I think there are GH API's for that.
Here's a zip file of a JSON dump of all the releases:
I've deleted all the releases and now GitHub is pushing users to the tags, which is good:
This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 7 days.