Address developer feedback on CHANGELOG

[freddyaboulton]

• I have searched to see if a similar issue already exists.

We've received some feedback on the CHANGELOG workflow:

• Merge conflicts are kind of annoying.
• Too many subsections under each release. Hard to know where to put the line for the change.
• Weird to ask users to put their username and pr number in the CHANGELOG since that can technically be automatic.

Describe the solution you'd like
As proposed by @aliabd on slack:

• All PRs automatically get added to the bottom of the Full Changelog section, without the developer doing anything.
• Instead of a CI check, it's a comment that reminds the developer that if they want to expand more on the change they should add it to one of the other sections (we can reduce the sections for sure, they're kind of arbitrary and I didn't think too much about them.)
• Otherwise, we can use tags to put them in sections like bug fixes, breaking changes, etc

Would be good to discuss with @pngwn before implementing.

Additional context
Add any other context or screenshots about the feature request here.

[freddyaboulton]

Additional comment from @pngwn - Let's have the CHANGELOG only reflect changes that impact library users. If we want to track changes to the repo we'd need a separate changelog.

[freddyaboulton]

Spoke to @pngwn today about V2 of the changelog. The proposal is to use changesets. Would love your feedback @aliabd @abidlabs (CC @aliabid94 @dawoodkhan82 )

Advantages

Before explaining how it would work for our repo, here are the advantages of this approach:

• No more merge conflicts as users edit independent files
• Version bumps are done automatically. This ensures we properly follow semver and eliminates human error from the release process.

How it would work

1. At the root of the repository we have a changeset directory.
2. When a user opens a PR, they add a file describing their change to the changeset directory
3. The name of the file does not matter - it should just be unique which is reasonable
4. A given changeset looks something like this (not finalized please let us know the feedback)

---
type: fix
bump: patch
---
Fixed bug in postprocess method of gr.Dataset

Basically, the change set file describes the change and has some metadata about the kind of change it is and the associated version bump. The bump can either be patch, minor, or major. And the type can either be fix, new-feature, breaking or docs.

5. We'll have a Github action that is triggered on merges to main. This action will check if there is a PR open with the name "Next Release" (the name doesn't matter - just that we have something). If the PR exists , the github action will rebase the PR to main and add the contents of all the individual changeset files to the CHANGELOG. It will also compute the next version number based on the maximum bump of all the changeset files and edit version.txt. If the PR does not exist, it will create it. This only happens when a release just got merged.

6. In order to do a release, we just have to merge the "Next Release" PR. Since this pr modifies version.txt the release github action will trigger normally.

Other notes

• In step 5, the github username and pr link will be automatically extracted and added to the CHANGELOG. Devs will not be expected to include this info in their changeset file.
• We're trimming down sections in the CHANGELOG. Each release will only have The CHANGELOG will only have the following sections : Bug fix, New Feature, Breaking Change or Docs. They map to the type field in the changeset file.
• If you want to embed a gif/image in your changeset file you can. We just need to make sure the github action in 5 properly preserves this.
• There shouldn't be any changes to the website since it currently builds from the CHANGELOG.md file at the root of the repo and that's not changing.

[abidlabs]

Amazing, this looks great! I like the formatting of the changeset file. Just one question:

• Would it be possible to generate a "blank" changeset file automatically when someone opens up a PR? I don't know if it's good practice for a CI action to modify the contents of a PR, but it would be really nice QoL enhancement if I didn't have to create the changeset file for each PR. If it could also popoulate the body of the changeset with the PR title, that would be 🤌

Maybe all of the changesets could be conventionally named <PR #>.yml

[freddyaboulton]

Thanks @abidlabs ! I agree having a pre-generated changeset would be nice QoL but I can't think of a way to do it that doesn't involve pushing commits to the branch from CI. Probably going to leave it out of scope for now.

[pngwn]

We could add a gradio changeset command that could ask the user for a version + a description and generate the file for them?

We could prompt them to do so in a PR comment + maybe do the github webgui add file thing via a link.