next.js

d2eb6216 - [release] enable changesets (#79035)

[release] enable changesets (#79035) This PR enabled changesets and is the initial entry point for transitioning to the new release process. ### Why? This follow-up stack of PRs will improve the current release process due to the pain points as follows: #### Pain Points ##### Users 1. The GitHub Release format was not user-friendly as it was based on the PR title, which may not include the full context. ^[issue-1] 2. The coupled versions of packages made the small packages iterate slower, e.g., breaking changes for `eslint-config-next`. ^[issue-2] 3. Lack of overall history in one place (Changelog). ^[issue-3] ##### Maintainers 1. The SemVer scope of their changes was defined after. ^[issue-4] 2. The GitHub Release of a failed canary release was left as a draft and had to be removed manually. ^[issue-5] See [Pain Points](https://www.notion.so/vercel/RFC-Improved-Releasing-Process-1c8e06b059c480e89608f8fdbfd9f600?pvs=4#1c8e06b059c480afbdc3d65b8b407828) from Notion for more. #### Improvements 1. The GitHub Release will be based on the summary of changesets the PR author should add. ^{[solves issue-1]} 2. The packages' versions are no longer coupled. ^{[solves issue-2]} a. All packages will still share the same tag (e.g., `canary`, `rc`, or `latest`) on release. 3. Generates `CHANGELOG.md` file. ^{[solves issue-3]} 4. Each change's SemVer scope is defined on creation. The changesets define the SemVer scope of the next release (following the highest). ^{[solves issue-4]} 5. The GitHub Release is published only after the successful NPM publication. ^{[solves issue-5]}