googleapis / googleapis/release-please

Consider tags on separate release branches / allow multiple stable release branches

Open
#2,202 4 comments 10 reactions 1 assignee Claimed by @chingor13 View on GitHub
priority: p3 type: feature request
Dominant language
TypeScript
Stars
7.5k
Forks
588
Avg merge
12h 16m
Merged PRs (30d)
7

Description

**Is your feature request related to a problem? Please describe.**
`release-please` currently expects all your release commits to be on the same branch you are releasing from. This doesn't work when you have multiple, long-lived release branches.

Our release process works as follows:
* We work off `main`
* When it's time to release a new version (major or minor) we create a branch off `main` at the feature-set we want to release
* Bug-fixes and security patches for release versions are later cherry-picked into these "release" branches (after being committed to main)

We are usually supporting at least the last 2 minors with patch releases. Using the `--target-branch` feature of `release-please`, we are able to release from these release branches, but since the release tags are on a commit on theses branches (which is desired), future releases on other branches can't find them. As a result, `release-please` doesn't find the correct previous release sha to compare to.

**Describe the solution you'd like**
I'd like an option, like `--consider-all-branches` that when specified, does not limit the search of commits for released shas to the current branch. Of course, we don't want to look at every commit ever in the repo, so in this flow I suggest release please uses github's graphql api for comparing commits between two shas.

**Describe alternatives you've considered**
I tried writing a custom GitHub action that brought in a lot of release-please code as a library, but that was a much more code to maintain than the changes necessary in `release-please` to support them.

**Additional context**
I have an initial solution that I will PR after creating this issue. It's a draft at the moment, as it needs some testing, but I want to get buy in on the approach before investing more time.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.