[Feature Request] Implement Conventional Changelog for enhanced/automated changelog generation

[jspizziri]

It seems like we've stopped using GitHub releases? As the most recent release is 2.0.1.

Recommendations

We should either:

1. Update the releases section and keep it up to date (with a script on publish?)
2. 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.

[dcvz]

@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

[jspizziri]

@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:

1. Add helper scripts to make it easy to issue commits like that.
2. Add linters to ensure commits are in that format in a GH action.
3. 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.

[jspizziri]

https://discord.com/channels/567636850513018880/600714011318681610/968551787936243774

[jspizziri]

@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.

[dcvz]

I think that would be fine @jspizziri ! I guess we'd lose some release notes but it'd be for versions no longe supported.

[jspizziri]

@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.

[jspizziri]

Here's a zip file of a JSON dump of all the releases:

releases.json.zip

I've deleted all the releases and now GitHub is pushing users to the tags, which is good:

[github-actions[bot]]

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.