Add a new "yarn release-notes" script to generate release notes

[anupriya13]

Description

Type of Change

Automate release notes creation by adding a new yarn script

Why

To save us some time when generating release notes. Before created it as a github workflow but now moving it to a local script.

Refer #14675 for context

Steps to follow

1. Set up your personal access token

• Go to GitHub and log in: https://github.com/
• Click on your profile picture (top-right corner), then click Settings
• On the left sidebar, click Developer settings
• Then click Personal access tokens > Tokens (classic)
• Click Generate new token > Generate new token (classic)
• Give it a name like "Release Notes Script"
• Set an expiration (choose less than 90 days)
• Under Scopes, select the permissions your script needs. For fetching commits and repo info, you typically need:
  repo (full control of private repositories)
  or at least repo:status, repo_deployment, public_repo (for public repos)
• Click Generate token
• Find the token you're using (whichever token you created).
• You should see a message or option to "Grant access to your organization" or "Authorize SAML SSO" for your token.
• Click that button to authorize the token with the organization.
• Copy the generated token

2. Set env variables at root of the repo

set GITHUB_TOKEN=<your-personal-access-token>
set RELEASE_TAG=0.79.0
set START_DATE=2025-05-06
set END_DATE=2025-05-30

3. Run "yarn release-notes" at the root of the repo

4. You will see a release-notes.md file generated at packages@rnw-scripts\generate-release-notes\release_notes.md which will have all the data you need.

Screenshots

Testing

Tested locally

Changelog

Should this change be included in the release notes: NO

Add a brief summary of the change to use in the release notes for the next release.

[jonthysell]

Why are we going through commits? Not every commit is included in the release notes by design. We generate the changelogs for every package, for every change, using beachball. It's what we put into each GitHub release.

If you want to automate writing the larger "Release notes", just load all of the local CHANGELOG.json files and process those. It's why we create change files to begin with.

[anupriya13]

Any issue in this way?
We want to format the PRs and this can give us more details on tags on PRs and we can utilise those too for categorisation.

For changelog we would have to iterate first for all
Packages and then filter dates.

With this script we will get more tight integration with Github APIs so it would be easier to scale this for future improvements like creating a Summary based on PR description, etc.

[jonthysell]

We have multiple release branches being worked on simultaneously, so the data is branch-specific as much as it is date-range-specific. Furthermore, each branch already contains a local json with actual changes based on change files, which filters out infrastructure changes (like pipeline changes) that shouldn't be in the release notes. Plus the data is already groups by release numbers, so you can just pick all the versions since a particular release, instead of relying on the date.

Querying the GitHub API for all commits feels completely unnecessary (if not also potentially wrong wrong) because the correct changes for each branch are available locally. Even if you didn't want to use the existing change infrastructure that powers all of our other release notes and changelog, you could just run local git commands for commits and avoid hitting the GitHub API.