Summary: when bors is configured to delete merged branches, it spares those configured as perennial.
Some projects have perennial branches that are designed to not perish after being merged into the main developmemt line. One typical example is a
develop branch that periodically getserged into
This document is motivated by the desire to use the same bors workflow (woth all bells and whistles) for that sporadic
In order to protect your perennial branches from deletion, if
delete_merged_branches = true, list them as
perennial_branches = [ ] in your bors.toml. This option has no effect if
delete_merged_branches is not set to
Before bors makes any call to the GitHub API that involves branch deletion or rebasing (
update_base_for_deletes), bors validates the branch name against the list of perennial branches by string identity. The condition to peoceed is that such branch is not contained in the list of perennial branches.
In order to keep the implementation simple, and corner cases comtained, no string wildcard implementation for the
perennial_branches oprion is proposed. Perennial branches are relatively non-noumerous, ao that this is not expected to cause major usability issues.
The condiguration api around beanch deletion grows without any resemblance of a homologized naming scheme.
Since the branch deletion is an englobing option, the obly viable alternative seems to be an excepting option list.
Not using bors for those types of merges (
main) would forgo some of bors' own workflow guarantees. Since in the described workflows, bugfixes can still land directly in
main, a situation can be construed where bors' guarantees are relevant.
If this is not implemented,
develop branch based workflows maintain a blind spot with respect to bors' workflow guarantees on
main merges, if they cannot trade off against switching off branch deletion (eg. on somewhat hogher volume repos).
git-town is known to name those type of branches perennial branches and implements a similar behaviour of sparing them from elimination, in the case of
git-town, both, locally and remotely.
Perennial branches can be also of temporary temporary nature, for example if a team decides to split off the
main branch temporarily for a longer sprint that is regularily merged back into
main. In such situations, it is easy to get confused where the usage of bors is apporpriate and where not. So much so, that frequently unintentionally deleted PRs trigger a lot of maintenance work: recreating that branch, reopeni g closed PRs or re-rebasing rebased ones.
Is excluding wildcard branches from the option an appropriate decision?
The issue of a growing list of branch related options without a harmonized naming scheme isnout of scope for this RFC and ahouls be addressed in future initiatives.
I don't see future upside.