mirror of
https://github.com/renovatebot/renovate.git
synced 2026-10-30 17:27:26 +00:00
Jamie Tanna
1fe48de57f
* docs(next-major): update links to Renovate 44 examples After the inadvertent release of Renovate 44, we still need to follow post-release actions, so we may as well keep these updated. * docs(next-major): add reference to major version bump in docs
95 lines
4.8 KiB
Markdown
95 lines
4.8 KiB
Markdown
# Major Releases
|
|
|
|
## When will we push a major version?
|
|
|
|
- There is no set schedule for major version releases
|
|
- If we need to bump the **minor** (or major) version of Node.JS required to run Renovate
|
|
- If we have a few breaking changes "piling up"
|
|
- If we have a need to introduce something that will need wider visibility (i.e. some changes to `config:best-practices` )
|
|
|
|
## Preparing
|
|
|
|
- Determine what's in the next release by looking at the [Milestones view](https://github.com/renovatebot/renovate/milestones)
|
|
- Look through [breaking changes in the Issues backlog](https://github.com/renovatebot/renovate/issues?q=is%3Aissue%20state%3Aopen%20label%3Abreaking) or in [the PRs list](https://github.com/renovatebot/renovate/pulls?q=is%3Aopen+is%3Apr+label%3Abreaking)
|
|
|
|
### Draft release notes
|
|
|
|
It is worthwhile drafting the release notes ahead of time, ideally on a GitHub Discussion or Issue, so you can preview what GitHub Flavoured Markdown would render as.
|
|
|
|
For example see [how v42 release notes were drafted](https://github.com/renovatebot/renovate/discussions/38841#discussioncomment-14770478).
|
|
|
|
## Branching workflow
|
|
|
|
When in the days before the release is ready to land:
|
|
|
|
1. Create a temporary branch for release, eg `next-major` (from `main`)
|
|
|
|
- This should **not** be a protected branch (including `next`), as we will be rebasing it regularly
|
|
|
|
1. Create a PR from `next-major` to `main`
|
|
1. Add the `ci:fulltest` label to the PR
|
|
1. Note issues to close as part of each PR
|
|
|
|
- Mark these as closed by the PR by setting them in the PR sidebar's "Development - Successfully merging this pull request may close these issues."
|
|
|
|
1. For each planned breaking change PR, rebase them + finalise the Git commit history
|
|
|
|
- Adding the `Closes #...` isn't necessary, as we've set this at a PR level
|
|
|
|
1. For each planned breaking change PR, change the base branch to `next-major`
|
|
1. For each planned breaking change PR, approve + merge them into the `next-major` branch
|
|
|
|
- **NOTE** that you want to be merging changes that may lead to conflicts (large code changes, some dependency bumps) to the last possible opportunity
|
|
|
|
1. If required, rebase `next-major` on `main` and re-push back to `next-major`
|
|
1. Wait for CI
|
|
|
|
## Releasing
|
|
|
|
1. Once `main` is looking quiet, `next-major` is up-to-date, and CI is fully passing, you can proceed
|
|
1. Use `git` CLI to push all commits from release branch to main
|
|
|
|
- **NOTE** that this is a "I'm going to `git push` and bypass branch protection requirements" rather than `git push --force`
|
|
- This needs to be separate commits, so they each get their own note in the CHANGELOG
|
|
- For v42 release, we:
|
|
|
|
```sh
|
|
git checkout main
|
|
git pull
|
|
# make sure we're using what's pushed
|
|
# also, do not edit anything interactively at this point, as it will break the PR closing mechanism if the commits are different
|
|
git rebase origin/next-major
|
|
# NOTE THAT THIS DOES NOT REQUIRE A FORCE PUSH
|
|
git push
|
|
```
|
|
|
|
1. Wait for release
|
|
1. Take draft release notes, and prepend them to the autogenerated release notes from Semantic Release
|
|
1. Create a Maintainer Announcement with the release notes
|
|
|
|
- And optionally add some additional commentary [i.e.](https://github.com/renovatebot/renovate/discussions/39133#discussioncomment-14890636) about the previous major release
|
|
|
|
> [!IMPORTANT]
|
|
> The final `git push` to `main` can be performed by users with the Maintain role, which includes all Renovate maintainers.
|
|
|
|
## Post-release
|
|
|
|
- Monitor Discussions for early insights about post-release bugs that need to be resolved
|
|
- Approve and merge the major bump to the documentation for the new Renovate version [i.e.](https://github.com/renovatebot/renovate/pull/44942)
|
|
- Update GitHub Action to next major
|
|
- Approve and merge the major version bump from Renovate, which will release the next major of the GitHub Action
|
|
- [i.e.](https://github.com/renovatebot/github-action/pull/1067)
|
|
- Ensure that the Action's new major version shows as default [in the marketplace](https://github.com/marketplace/actions/renovate-bot-github-action)
|
|
- Update GitLab CI configuration to next major
|
|
- [i.e.](https://gitlab.com/renovate-bot/renovate-runner/-/merge_requests/3346)
|
|
- Add a copy of the JSON Schemas to Schema Store
|
|
- Go to the last tagged release (of the last major version) and download `docs.tgz`
|
|
- Copy the `renovate-schema.json`, `renovate-inherited-schema.json` and `renovate-global-schema.json`
|
|
- See [schemastore#6142](https://github.com/SchemaStore/schemastore/pull/6142) as an example of what configuration may be needed to have the PR build pass
|
|
- Close the Milestone for the release
|
|
- After some time (usually when the Mend Developer Platform has been live with the new major), mark the previous major version as deprecated:
|
|
|
|
```sh
|
|
% npm deprecate renovate@"<44.0.0" "Renovate versions older than the latest major version are unsupported"
|
|
```
|