Jeff Ching

v1 and v2 are distinct APIs that don't share any RPCs :(

Release-Please needs to look at files touched in each commit to decide which commits apply to which components. Currently, everything uses the GitHub API for all the data -- it...

This is an upstream issue on release-please but related to what git decides is a conflict. Both PRs are touching the same file on different lines, and in theory this...

Please try with the latest upgraded version which should have fixed this.

The changes in the latest versions of release-please were around the branch name used. `package-name` should only be necessary to configure if you are using `monorepo-tags` (component prefix in the...

> Which config do you mean? The GitHub action config for release-please-action > ⚠ Duplicate release tag: tagName The action tries to tag release PRs. It seems it's finding a...

Sorry for the delay in getting to this issue. If you are not using manifest configs/version file which explicitly declare the latest version, then release-please needs to [figure out what...

Ah, I see. Our primary use case for multiple release branches is for handling LTS/backport versions. In our usage: `main` contains the latest version (say 2.1.3). We'll also have a...

This was fixed in #474

> I'm not sure that the job outputs `steps[STEP_ID]outputs.releases_created` will be set properly if you trigger the release at any state of the repo as opposed to the release triggering...