Automated Release Notes

[freddyaboulton]

Description

Fixes #1718

Colab with @aliabd 🙌

Overview dev workflow when opening a PR

• Developer opens PR
• The Check CHANGELOG file GH Action will run. If the dev has not modified the UPCOMING.md file to include a line with the pr number, the check will fail. The PR template explains what's going on.
• If for whatever reason, we don't want to add the PR to the release notes add the no-changelog-update label
• PR gets merged and the website builder will convert the files in website/releases into the changelog page.

Overview of changes to release workflow

• After the release PR gets merged. The release pipeline will trigger as normal. After the pypi deployment and gh release go out, we run a script that copies UPCOMING.md to be {{ latest-version}}.md and then reset UPCOMING.md to match TEMPLATE.md Check this out on my gradio fork
• If the release is a draft release (contains b in the version number), we will not reformat the change log files. Check this on my fork

Checklist:

• I have performed a self-review of my own code
• My code follows the style guidelines of this project
• I have commented my code in hard-to-understand areas
• I have made corresponding changes to the documentation
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes

[github-actions]

All the demos for this PR have been deployed at https://huggingface.co/spaces/gradio-pr-deploys/pr-2306-all-demos

[github-actions]

Hello 👋 and thank you for contributing to Gradio! All pull requests must update the change log located in website/CHANGELOG.md unless they are labeled with the no-changelog-update label.

Please add a brief summary of the change to the Full Changelog section of the Upcoming Release and include the pr number. For example, "* Added a cool new feature :pr:123". Note the backticks around the pr number.

If you would like to elaborate on your change further, feel free to add it to also include a longer explanation in the other sections.

[abidlabs]

Will this rerun if a PR is updated? i.e. if someone pushes more commits to an open PR?

[freddyaboulton]

Yes!

[abidlabs]

Great work guys! This looks really good - see some questions and suggestions above

[pngwn]

This looks awesome, great work @freddyaboulton @aliabd!

Few questions:

• Why aren't we following the standard changelog format of having a single CHANGELOG.md in the root of the repo? That is the typical way of handling changelogs in and is also what people unfamiliar with the project will look for. This is a 'standard' changelog. The benefit of a single file is that people often don't know what version they care about, they may want to see features changes over time or see when a specific feature was introduced or PR merged.
• Will this fix the issue with us not having changelogs for patch versions?
• Can we make the markdown itself as readable as the website page? That is why markdown is used for changelogs, so they are readable as raw text or in github. Currently we seem to be replacing the :pr:2357 shortcode in the website build, this link should also be present in the markdown file. I personally always view changelogs in github, currently it looks like this, users and PRs need to be linked appropriately.

[freddyaboulton]

Thanks for the comments @pngwn !

• We originally started with a single file (not in root of repo) but we felt that it would get hard to edit a single file as time went on since the file would get big with the images/gif/code snippets we plan on adding to highlight the major features. I'm ok with having a single file at the root of the repo though if it's more in line with conventions. What do you think @aliabd ?
• Yes. We'll have release notes on github and the website for every release. They won't automatically appear on the github release created during the deployment action but we can manually copy them over if we want.
• Yea I can add the full pr link and author tag to the markdown files in the repo. Would probably make @aliabd 's life easier on the website lol

[aliabd]

I'm fine reverting to a single changelog file, especially if it's standard. @pngwn made a good point about users reading it on github and not caring about specific versions but wanting to see a full list of changes.

[pngwn]

@freddyaboulton

They won't automatically appear on the github release created during the deployment action but we can manually copy them over if we want.

There is actually a GitHub API for this if we wanted to add it later.

[pngwn]

This is great. Awesome work folks!