Staging and Production Overview

[vlazed]

Diagram

graph TD;
    subgraph SubGraphA[Forks]
        A[Fork 1] --- B;
        B[Fork 2] -.- C[Fork N];
    end
    SubGraphA <-->|pushes to/pulls from| D[Peak Inc SMH];
    D -->|pushes to| E[Winded SMH];
    E[Winded SMH] -->|push| F([Workshop Main Version]);
    D -->|pushes to| G([Workshop Beta Version]);

Loading

Notation

• Peak Inc SMH: Peak-Incompetence/StopMotionHelper
• Winded SMH: Winded/StopMotionHelper

Pushing / Pulling Method

Each fork pulls from Peak Inc SMH. To make changes to Peak Inc SMH, the fork should

• Create a branch,
• Create a PR of the changes from the branch, and then
• Squash and merge its changes over.

This results in a clean history where the details of such changes can be viewed under the PR commit message. In addition, the PRs are reflected over in the workshop's changelog. Squashing and detailing the changes in a single PR commit reduces the volume of commits in the commit history.

Let's make the changes incremental. If you plan to make a big change to a subsystem of SMH, you should PR changes by part (see #24 and #29). It's harder to test a big PR, especially if it rewrites an existing workflow. If several subsystems within the PR breaks an existing workflow or introduces bugs, then the developer would have to look for particular commit/subsystem that broke, while also ensuring other subsystems are not broken; this increases development time and introduces delays as a consequence. By limiting the size of a PR, this ensures that each part of the PR gets completely tested in the workshop beta version.

Finalizing Squashes in PR

When pushing a PR (or any commit) to this repo, a workflow activates to automatically update the beta version. It transforms the commit message form Markdown to Steam BBCode. As of 7/6/2026, some Markdown formatting can reduce readability and also produce incomplete change notes. To reduce this, observe the following rules for the PR commit message:

• Inline code resolves to code blocks. Use italics instead
• Double quotation marks ("") prematurely ends a change note. Even then, backslashes (") do not completely resolve this issue. Use single quotes instead.
• Put bulletpoints together. Failing to do so will produce [list][/list] islands
• Add 4 spaces for sub-bulletpoints, so that the Markdown-to-BBCode transformer can create a sublist (nested [list]) within the list.