Permanent Branches and their Maintainers

Currently, cabal has a simple branching scheme: apart of the ephemeral PR branches there is the master branch for ongoing development and one release branch for each major release. E.g., a single branch 3.10 for the 3.10.* release series, 3.8 for 3.8.*, etc. Minor releases are marked on a branch with a tag. Normally, PRs are created on the master branch and backported, as needed, to any other branches. Normally, a new release branch is created by forking the master branch at the tip and is managed by the Release Manager for that branch.

At any given time, the active branches are: the master branch, the last release branch and any old release branches that have owners. The job of a Release Manager is to coordinate the making a particular release. The job of the Branch Maintainer, who is the owner of a particular old release branch, is as follows, with the 3.10 branch used as an example:

The main goal of the Branch Maintainer of the 3.10 branch is to help long-terms users of that release series (e.g., Linux distro maintainers) by giving them a consistent Hackage and repo code base to work with. In particular, the users are going to compile cabal 3.10 from source many years after the last 3.10 release, using a mixture of new and old packages and GHCs. Your job is to take ownership of the 3.10 branch in the repo and do your best to keep it in good shape (until it's officially retired), which includes:

• note, highlight, participate in, initiate discussions related to the 3.10.* cabal versions and encourage PRs (e.g., for bound bumps) whenever the users seem to need them
• alert all maintainers if impossible happens and a new release in the 3.10 series may potentially make sense (but don't worry, releasing 3.10 is not a part of this job at all)
• keep CI on 3.10 branch operational, e.g., by backporting CI fixes, for as long as feasible
• merge or bring up for discussion outside PRs to the 3.10 branch
• revise 3.10.* bounds on Hackage according to the cabal packages revision policy in response to PRs
• keep the bounds on Hackage and on the branch in sync (say, inspect quarterly)

The Release Manager and the individual Branch Maintainer jobs are meant not to be taken by the same person. The Release Manager job is meant to be rotational (perhaps a couple of minor releases for a single maintainer), while the Branch Maintainer position would normally last until a branch is officially retired.

For branch 3.12, especially if the release gets designated as a Long Term Support release, the Branch Maintainer job could be extended to general backporting (not only CI), in a more and more selective manner as the branch gets older. That would also make rare bugfix 3.12 releases interspersed with 3.14 releases realistic, as opposed to 3.10. Whether cutting the late releases would be among the 3.12 branch maintainership responsibilities is negotiable.