[META] Repository structure and release process

[Histalek]

Motivation

In the most recent release our current release process and repository setup lead to some issues that we would want to prevent in the future. In no particular order:

• Waiting on fixes of an already merged-to-master feature, preventing the release of bugfixes
• being "locked" into releasing a minor release (v0.X.Y increase X) instead of a patch release (v0.X.Y increase Y) once ANY feature lands in master
• as a consequence of the above two issues: increase in testing time needed and hence further delay of bugfixes as we need to test all merged features instead of only the bugfixes

Proposal

I want to outline the steps for a possible solution to this problem which:

• doesn't change current users/serverowners workflow/usage who run directly on our default git branch
• doesn't change the way PRs are handled
• does however add two different workflows for feature and patch releases

In short we would add another protected release (i'm open to naming suggestions) branch.
The goal of this branch would be to track and be the canonical source for any steam workshop releases e.g. this branch should be used to collect and upload the files to the workshop.

With the addition of this branch there is no change for any existing interactions for non-teammembers with our repo:

• the default branch (! not the release branch!) can still be tracked by consumers that want to run our 'development' version
• general PRs still target the default branch and can be merged how it's done today

Changes to implement

The only changed workflow is on us regarding the release process which is now split into two different processes depending on if a minor or a patch release is targeted.
Both of these workflows would consist of two different PRs: a "content update" PR which brings in all wanted commits for the targeted release and a "release" PR which we have done for some time now.

Minor release

Content update PR

This is somewhat straightforward and would mean merging/rebasing (NO SQUASHING!) the default branch to the release branch. Any previously applied/cherrypicked bugfixes should be skipped by git.

Release PR

Follow the steps of our current RELEASE_PROCESS.md .

Patch release

Content update PR

Cherrypick all wanted commits from the default branch and put them into a single PR.

Sidenote: We probably want to explicitly ban commits that introduce migrations from this (which probably should never be bugfixes) to prevent any issues on that front.

Release PR

Follow the steps of our current RELEASE_PROCESS.md .

Automation

In line with our efforts in #1191 these steps should also automated as best as possible.

As far as i can see every steps besides the 'patch release content update' PR can probably be automated. The 'release PR' can probably be triggered by any merged PR on the release branch. In which case we would only need some sort of signaling if it is a minor or a patch release (a keyword in the PR title probably works).

As for the content update of minor releases this could be a workflow that could be manually triggered by us. There is a small possibility that this could fail due to conflicts, but in that case a manual PR is also possible and straightforward.

Other / Related

• rename master branch to main
  • this shouldn't really affect anyone as github automatically redirects renamed branches as long as there is no branch with the old name
  • probably announce this rename in the announcements channel on discord (no at-everyone needed IMO)

Closing

Please let me know your thoughts! did i miss anything? Are there any open questions?

[EntranceJew]

these are the types of challenges git-flow is designed to solve

[Histalek]

these are the types of challenges git-flow is designed to solve

Git-flow builds upon the already broken UX of git itself, anyone i know of that used git-flow dropped it again shortly after.

Beside this anecdotal tale, git-flow is way overkill for us and would force at least 4 people to adopt git-flow for a single of their repositories. Which is unneeded for what we need.

This proposal should be the minimal set of changes needed to prevent the outlined issues at the top of this issue.

EDIT: I mean just look at this, nobody can tell me that this kind of complexity is ever justified for a project like ours