On dmd 2.112, future releases, and LTS

[Dennis]

This year I took over the release process from Iain, not because 
I am so qualified as a 'DevOps Engineer' (I actually had to look 
that term up) but out of necessity. Therefore I planned to just 
'cruise' for the time being and follow the existing process 
without touching anything. However, the current release process 
causes so much friction that I want to change it sooner rather 
than later. For the Symmetry Autumn of Code (SAoC), there is an 
idea for a project to streamline the release process. This is 
mostly about the infrastructure for building releases and 
uploading the downloads to the server. What I want to discuss now 
is the release schedule, branching strategy, and contributor 
experience.

## Issues with the current process
- The distinction between the master/stable branch is vague and 
time-dependent. Some say stable is for 'critical' bug fixes, 
other say it's for 'safe' bug fixes, but DMD's semantic analysis 
order is so fragile that even 'safe' bug fixes have caused 
projects to break after an update from release candidate to 
actual release version.
- Pull Requests that target the default master branch often 
contain discussions "please rebase to stable", "won't do because 
X", "will do because Y", "okay I tried but now commits are all 
messed up", etc. This wastes the contributor's and reviewer's 
time.
- Stable constantly needs to be manually merged into master to 
prevent conflicts and keep nightly up to date
- Patch releases are not possible after master gets merged into 
stable. So once I build a beta for 2.112.0, I can't build 2.111.1 
anymore.
- Relatedly, people have requested LTS (Long Term Stable) 
releases which don't fit into our current branch structure
- The frequency of beta, release candidate, and patch versions is 
high, adding to the workload of the release manager while there 
are still so many manual steps in the process. Following the 
existing cadence I'd build 4 releases in a span of 4 weeks. Many 
of these releases only differ by a handful of commits, and while 
there is no urgent problem with server storage, the gigabytes are 
slowly piling up.
- To add to that, only a small percentage of people actually seem 
to actually test beta/rc versions. Most regression bug reports 
come in after a release has been pushed to package managers.
- Releases are tagged purely based on time, even when we're in 
the middle of a series of incremental pull requests, causing 
half-finished work to unintentionally appear in a release 
sometimes.

## Proposal
- All contributions go into the master branch.
- Every 3 months a feature freeze for a minor version is created 
in a branch called 2.XXX
- Maintainers can add a 'backport-to-2.XXX' label to a PR, 
triggering a GitHub Action to merge it into that version branch 
(unless there are merge conflicts, then manual action is required)
- 'stable' points to the latest minor release branch for 
backwards compatibility
- Nightly builds continue as always, being built from master
- Consider making 1/4 releases (or 1 per year) Long Term Stable 
(LTS)
- Backports to LTS / feature branches are done on an as-needed 
basis. Patch releases aren't created based on whatever bugs 
happened to be fixed the month after the first minor release, but 
because critical bugs/regressions popped up that prevented 
(industry) users from getting work done.
- Try using GitHub milestones to coordinate features with release 
versions

Maintainers still need to decide what master commits go into what 
version branch, and merge conflicts can still happen, but at 
least this should remove most accidental complexity. We no longer 
need to pester authors of Pull Requests about which branch to 
target, and there's much more clarity on what's happening: You 
don't need to cross-reference the release schedule with the PR's 
merge timing to figure out where it's ending up.

## Feedback

If I missed any (technical) considerations, please let me know. 
This is just my proposal based on current observations, it can be 
adjusted as we go. For example, the frequency of releases can be 
increased if there's demand and the process gets streamlined.

## Current status

I won't implement this before DConf, I'm currently focussing on 
building 2.112.0. I need to update the Visual Studio installation 
on the Windows VM to make that work. I'm also looking to add a 
certificate to the MacOS releases (courtesy of @LunaTheFoxgirl, 
thanks!), which also requires changing what happens inside the 
MacOS VM. Like I said, this is all new to me, so if anyone wants 
to help out that would be appreciated.