Summary: when bors is configured to delete merged branches, it spares those configured as perennial.
I allow this RFC document to be modified and redistributed under the terms of the Apache-2.0 license, or the CC-BY-NC-SA 3.0 license, at your option.
Motivation
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 main.
This document is motivated by the desire to use the same bors workflow (woth all bells and whistles) for that sporadic develop to main PR.
Guide-level explanation
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 true.
Reference-level explanation
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.
Drawbacks
The condiguration api around beanch deletion grows without any resemblance of a homologized naming scheme.
Rationale and alternatives
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 (develop → 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 develop → main merges, if they cannot trade off against switching off branch deletion (eg. on somewhat hogher volume repos).
Prior art
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.
Unresolved questions
-
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.
Future possibilities
I don't see future upside.