Template variables support for release-pr branch name

[AdamStrojek]

Motivations

Currently we can provide static text as pr_branch_prefix in config file. This solution is not that flexible, and requires using suggested branch naming strategy. I think it would be better to replace it with template system that allows you on providing such configuration:

[workspace]
pr_branch_template = "release/v{{ version }}"

If somebody wants to remain current behavior we can leave pr_branch_prefix as legacy option that would automatically be interpreted as:

[workspace]
pr_branch_template = "{{ pr_branch_prefix }}-tmp-{{ date }}"

If instructed I can implement this feature

[marcoieni]

I agree with you that pr_branch_template is better than pr_branch_prefix.
The issue is that release-plz in workspaces has more {{ version }}s. What should release-plz put in that variable in this case?

Plus, the version could change (e.g. because there's a new breaking change and so instead of 0.4.1 is now 0.5.0). The branch will change so release-plz needs to close and open a new PR. So much complexity added! Is it worth it? Why is the current prefix not good enough for your purposes?

[AdamStrojek]

I understand that the additional complexity introduced by this approach may not be suitable for everyone. However we don't need to force users to use mechanisms that are not suitable for their project. Some of this variables can be exposed with annotation that there is no guarantee to work under some known circumstances (your example with multiple projects in workspace) and yet for my flow it address my needs.

Currently I'm not using whole GHA flow. I have removed part responsible for creating release PR after changes merged to main branch. My release flow can be explained in this few steps:

1. I work on changes in separate feature branches, once feature is finished I merge it to main branch
2. In single release I can collect multiple features
3. When new version is ready I manually trigger release-plz release-pr, this prepare new branch in my naming convention
4. Rest of GHA flow remains uninterrupted, after merging new release is prepared and send to crates

Naming convention is important for me to standardize way how I construct changelog file.

As mentioned earlier, I'd like to contribute to this project by implementing the feature discussed. To do so effectively, I'd greatly appreciate it if someone could point me towards the relevant files that I should be interested in. This would help me get started on a more focused path and ensure that my contribution aligns with the existing codebase.

[marcoieni]

as a workaround, since you work locally you could also run relase-plz update and then create the PR manually. But maybe you have already considered this.

[marcoieni]

sorry I clicked close by mistake 😅

I understand that the additional complexity introduced by this approach may not be suitable for everyone

The complexity mainly is added to the release-plz codebase. Implementing this feature might be tricky and release-plz will become more difficult to maintain maybe. I need to think about this. 🤔

Naming convention is important for me to standardize way how I construct changelog file.

What naming convention do you have if I can ask? I want to understand the use case to evaluate if it's worth implementing this feature