docs: document configuring multiple release branches

[chingor13]

Towards #244

[bcoe]

@OrenMe don't suppose you'd be willing to try these docs out, and see if it work for your patch based workflow?

[OrenMe]

@bcoe This looks good, but it also requires to have some prior knowledge of the branch prefix.
What if I have 1.2.0 released and I now add a few features and fixes to the main branch so my next version is 1.3.0.
If I now need to release a patch I need to have the default-branch be set to 1.2.x
And if I have monthly releases so next month I'll need to patch it to be 1.3.x and each time I need to patch the workflow file.
Maybe add it with a branch name regex so it can be done dynamically?
If I open patch/1.3.x then it resolves against the latest 1.3.x tag available for the change list resolving.
Of course the regex pattern can be set as a param to allow custom names for patch branches.

I also tested this and it acts funny with the main branch PR that release-please opens.
It looks like you need to first close the open PR against the default-branch if it is already opened(which most likely it is)

[bcoe]

I also tested this and it acts funny with the main branch PR that release-please opens.

@OrenMe what behavior happened?

[OrenMe]

@bcoe it reused the same PR that was already opened for the main branch and iirc it was kind of messed up in commit order as it didn't take it cleanly from the new patch branch.

I think it can be better if new target branch PRs be separate and not reuse a single PR across targets.

[bcoe]

@OrenMe I think this is an issue @chingor13 brought up with me already, which happens if the alternate branch and the current branch share the same version range.

The plan to solve the problem is to move to a new branch naming format, which includes the name of the target branch.

[OrenMe]

Thanks @bcoe, sounds like that will do the trick.
Is there a tracking issue on this I can subscribe to?

[bcoe]

@OrenMe created tracking issue here:

googleapis/release-please#808