Awesome!

I think for this to be maximally useful we need to somehow enforce that the commit messages of our squash commits that go into the main branch follow the conventional commit format.

I think we do have a presubmit that checks this when committing locally, but this is not run upon squash merging a PR.

Any idea how we could enforce properly formatted messages for these squash merges?

I think for this to be maximally useful we need to somehow enforce that the commit messages of our squash commits that go into the main branch follow the conventional commit format.

I don't have a good solution to that at the moment. ... but that's also a separate issue from this PR, right?

FWIW, I'm bogged down at the moment on the lack of support for prerelease versions in release-please. I'd really like to get this setup for the rfc4122bis branch so we can publish to NPM using "9.0.0-bis.#"-style versions, but blocked by this issue. (I'm not well-versed in how release-please works, though, so there may be a workaround...?)

I think for this to be maximally useful we need to somehow enforce that the commit messages of our squash commits that go into the main branch follow the conventional commit format.

I don't have a good solution to that at the moment. ... but that's also a separate issue from this PR, right?

Correct, it‘s an independent issue. However I‘m wondering if we should fix the conventional-commit enforcement first? I think release automation can only reliably pick the right major/minor/patch version to increment if the commit messages obey the conventional commit rules. Otherwise we may end up with release-please creating minor bumps for breaking changes. OTOH it only generates a pull request so we still have human supervision. Given that, I think the order in which we do those two things actually doesn’t matter.

This can be closed here right? Got merged and shipped in v10.0.0 as I see in the changelog.

@Shooteger: No, this about improving the release process in general, not about pushing out a specific release.

@ctavan @pmccarren FWIW, the standard-version (that we depend on) was deprecated last year and now recommends using release-please instead: https://github.com/conventional-changelog/standard-version

'Not really sure how well this is going to work but this PR is long in the tooth and the way release-please works makes it difficult to properly test on a branch. So I'm merging and will work the kinks out as part of rolling v11.