🛠 Tooling: switch from `release-it` to `release-please`

[michaelfaith]

Tooling Report Checklist

• I have tried restarting my IDE and the issue persists.
• I have pulled the latest main branch of the repository.
• I have searched for related issues and found none that matched my issue.

Overview

We talked about some of the changes we need to make to our release workflow as part of our shift to stable releases in our last sync, and I wasn't familiar with release-please before now, so my suggestion was to just stick with release-it, and to just remove it from the main merge workflow. Now that I've had a chance to take a deeper look at release-please, I think it might be a good option for us. It addresses several of the issues we discussed, and there are good example of other projects using it (e.g. eslint-plugin-eslint-plugin). So, I thought it would be worth revisiting.

Just to sum up the considerations:

1. We need to be able to release on demand, rather than release on every merge to main
2. We need some way to land breaking changes well enough in advance of a major release, without blocking possible minor and patch releases going out before we're ready to major
3. Should support pre-releases for next or beta releases of the next major version before it's release-ready
4. Should support all of the auto-generation of GH releases and CHANGELOGs, as well as the ability to auto-tag the repo and publish to npm that we have today

release-please supports having multiple target-branches, which solves problem number 2. We could have main and next branch, or 2.x.x style branch that is "main-like". We could configure release-please to use a pre-release version strategy for releases from the 2.x.x branch (which solves number 3), and target that branch for any breaking changes in the lead up to the major. The way that release-please builds up a release PR and only publishes after that release PR is manually merged solves number 1. And then it supports all of the requirements from number 4. Not mentioned, but it also supports the same conventional commits syntax that we use for changelog creation.

The only minor thing that I think we might loose, unless this is configurable too, is that the releases and changelog entries that release-please generates don't mention the issue that a change closes. It does link the specific commit of the change as well as the PR, but it doesn't mention the issue number tracking the change.

Examples:
Release Please

Release It

Notice they almost look identical, except for the "closes #..." portion. I don't think that's a deal killer, but just calling it out as a gap (unless there's config for that that I haven't seen).