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
• Look through breaking changes in the Issues backlog or in the PRs list

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.

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
2. Add the ci:fulltest label to the PR
3. 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
2. 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
2. Wait for CI

Releasing

1. Once main is looking quiet, next-major is up-to-date, and CI is fully passing, you can proceed
2. 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:

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
2. Take draft release notes, and prepend them to the autogenerated release notes from Semantic Release
3. Create a Maintainer Announcement with the release notes

• And optionally add some additional commentary i.e. 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
• 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
  • NOTE that you will only see 1 PR in the future, but in the last release, we saw 2:
    • i.e.
    • i.e.
  • Ensure that the Action’s new major version shows as default in the marketplace
• Update GitLab CI configuration to next major
  • i.e.
• 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#5294 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:

% npm deprecate renovate@"<44.0.0" "Renovate versions older than the latest major version are unsupported"