feat: Support monorepos

[apricote]

Many people use monorepos, where different directories equal different releasable programs.

• Identify which part a tag belongs to
• Create different versions/prs/tags for each part
• Decide which part should hold the "latest" tag

[simonostendorf]

I would love to see this because I currently use release-please for a helm-charts repo that contains many helm charts and a switch to releaser-pleaser would be great because of the nice pre-release functions.

[Jorgagu]

@apricote Do you have any ideas on how to implement this, or would you like some help?

[apricote]

This issue has a lot of depth that needs to be discussed and decided before working on an implementation. The following open questions come to my mind. I would gladly get some help in figuring this out.

Mechanics of defining the versions

How to figure out which "parts" are changed in each PR?

Do we support "single version" workflows? Where multiple packages may have independent functionality and changelogs, but all versions are bumped together? IIRC this is common in JavaScript monorepos with Lerna.

Updating Version References

Right now the generic updater bumps all version references that have a x-releaser-pleaser-version marker in the file, how do we know which version to use if we have multiple? This is relatively "simple" if we assume the files are always in the right directory, but a root README.md or other docs may want to include multiple versions.

User presentation

Should there be a single release PR that includes version updates for all "parts" or one release PR per "part"?

A single release PR becomes difficult to edit when there are multiple releases, we need to parse multiple code blocks for prefixes and suffixes. The labels also need some work, as they only work "globally" right now.

For multiple release PRs this becomes a lot easier, but then you also have X release PRs that you need to merge. If we support a single version workflow this option is pretty annoying.

Intra-repo dependencies

Should we bump intra-repository dependencies? For example in my repo hcloud-upload-image I have a Go lib at ./hcloudimages and a Go CLI at ./. The CLI depends on the Go Lib, but now my release process looks like this:

1. Merge lib release PR and wait for release
2. Create PR to cli to bump lib dependency to new tag
3. Merge cli release PR and wait for release

Not sure how to do this cleanly in different languages, and even with plugins for each language this would require us to know the hashes for various lock files.